Agent-native software architecture (2026-04-27, 13:25)

Source voice memo. The synthesis lives in Agent-Native Software Architecture (concept page) and There is no main js (essay draft for Posts). This file preserves the raw transcript for provenance.

Transcript

So I was recently thinking about this whole concept of an AI native software essentially, because I’ve recently seen like projects on GitHub that are essentially software, you could call it that, but there is no real code. There is no main.js. There’s the only code there is is like helper scripts and nothing else. And so, well, how it works is that it usually is using cloud code as the runtime, but it may also work with open code or some other agent orchestrating uh agent runtime that basically supports skills and sub agents and MCP and all the latest stuff.

And then what how the program works is that in the main agent file which may be cloud.md or just agents.md, it describes the program which is roughly equal to a main.js file or well a main program file that boots up the project or the program. And then everything else or well in a nicely structured project, at least everything else happens in sub agents and so you can think of a sub agent as a class maybe.

It’s not 100% fitting, but a class is a pretty good analogy I guess. Uh, and well, the main agent basically is the is is just orchestrating and when it does something, it calls. Agent accordingly. And so, well, now the sub agents have some high level description of what they do. It’s kind of like the class.

And then for the functions of the class, that’s usually where skills come into play. Um, so a skill is a function, for example, how to retrieve an information from this website or something similar. And yeah, so then there’s also, that’s how it usually works.

Like the sub agent gets called and the sub agent is scoped to have access to some skills that, well, are defined in the agent configuration. so in cloud code you can define sub agents which have basically their instruction files and then also some uh skills you can select, and then you can also select or add like helper scripts. these are usually parts of the skills themselves.

So you can call that a function. And then what’s also interesting is uh the next layer which is MCP and CLI tools. These are usually just used inside of functions or well skills and they they act as a sort of API.

If you come from traditional programming, that would be your API or maybe yeah, API or some SDKs basically that allow you to interact with external data and external sources accordingly connect basically.

It’s just connectors essentially. And that’s also one point. And then well, for keeping state or similar, you can just still use existing databases via MCP, CLI or just some stupid JSON file. And so in a clean agent native software architecture, you would call that probably that’s how it works.

There’s the main agent orchestrator who does on its main threat basically not do any any real work.

Just delegates all the time. and that also allows for parallelization and keeping things clean and also keeping permissions clean because like most sub agents won’t need full bash access um and that’s a good thing I guess. So that’s just one observation I made on this new kind of well software that’s emerging and I also build some projects myself and it’s quite interesting because it feels like a software even even though you didn’t implement anything and no no real code at least and so it kind of feels like well, you’re interacting it through it through the terminal mainly so it kind of feels like back in the day when the first programs came out before the GUI phase.

User interfaces didn’t exist yet and people typed into the terminal and that’s kind of how it feels.

It’s kind of awkward to use honestly.

Mostly there is like a setup script that you use or run once where they where there is a little setup agent that just saves user preferences and stuff. And then you just use skills as slash commands.

And these are not skills and well these are the same kinds of skills but they are usually there are user facing skills and there are helper skills basically. These helper skills are functions that you would not normally not call as a user but there is also top level ones that are essentially skills of the main agent also accessible to the user.

However, as a user currently you see everything which can be a bit confusing. And yeah. The user experience is kind of it it works but it’s kind of bad right now, it’s kind of slow. These kind of programs are kind of slow.

Also they have no UI currently. Um, you can create a wrapper yourself if you use the cloud code SDK and then build your own UI around it.

I think that’s a nice idea but most of the these projects are just cloud code projects, no custom UI. And I’m also not sure if you really need a UI for that. So that’s another question. And then what also what I found interesting about these programs is that they are self-healing.

So usually when you have a bug in your software, traditional software, you need to uh fix it and create a new release. However with these cloud code agent native software like it is not immutable the software is not immutable. You can just if you have a heal agent for example or a fix skill agent that agent can then be called if something goes wrong to basically debug the skill and then fix it for example if one of your skills broke because some MCP server changed its function but in the skills it’s still listing the old tools like you don’t need a create a release currently because it’s so dynamic and it’s not immutable.

I’m not sure if that’s a good thing or bad thing.

I mean imbility is usually a good thing but um In this case it’s quite interesting actually because you well, it feels really interesting.

I haven’t had that feeling in software having such self-healing functionality there. It actually feels like it’s really powerful.

Related

• Agent-Native Software Architecture — concept page (synthesized from this memo + the 13:49 follow-up).
• There is no main js — essay draft built on these two memos.
• 2026-04-27-Debugging and speed for AI-native software — companion memo (24 min later, same train of thought).
• 2026-07-01 — 10ten sync (private) — the product corollary of this architecture memo: in a work call the user argues that products increasingly need native high-quality MCP / API / CLI surfaces because now everybody has their own agent to integrate with it, naming the Monologue voice-notes app (MCP + CLI + API) as the example. Agent-native isn’t just how you build software here — it’s becoming table-stakes for what users expect from any service.