Loading...
tl;dr — A few markdown files is is all the material you need to build an application. Write down what it should do and hand that folder to an agent harness. With a model and tool use, those documents can become working software.
How does describing an application get so close to having one?
Simplification: let's describe an application as a program, some state, and the machinery that runs it.
Cast that into some slightly more specific terms, we get the following table.
| Role | Mechanism | Function |
|---|---|---|
| Runtime (R) | Harness | Assembles context, runs the interaction loop, mediates tools and actions. |
| Interpreter (I) | LLM | Uses context to propose responses, actions, and changes. |
| Program (P) | Files | Specifies goals, constraints, and behavioral guidance. |
| State (S) | Files | Holds preferences, resources, records, and working memory. |
The Agent is A = (R, I, P, S). It contains both the program and the system that runs the program. The Agent is a pattern of behavior realized by the interaction of the parts. Changing any of the parts can change that pattern. The Agent is reshaped by changes to its machinery.
In conventional software, an application's behavior is largely specified in advance through explicit rules in strict syntax.
Here, the intent is expressed in natural language. The interpreter works out what the instructions imply in the current situation and uses available tools to turn them into behavior.
The document's intention runs in this practical sense: interpretation produces behavior. Prose express software through the system that interprets it.
A useful application can exist without a conventional software stack. You author a few documents, let the Agent turn them into behavior.
And since those documents are readable and writable by the Agent, you can also change the application by talking to it.