If you've been following my thesis on Adaptive Software, we've covered two of the three core components required to build systems that evolve around their users rather than prescribing how they work.
- First, I outlined Progressive Determinism in Code Over Config—the process by which a system observes AI-mediated behavior, learns the patterns, and compiles them into deterministic code paths.
- Then, in Layered Context, I explored the architecture of Adaptive Memory, breaking down the four layers (Ontology, Character, Workflow, Memory) that allow an agent to actually learn rather than just retrieve past conversations.
But there is a missing piece. You can have a system that learns, and you can have a memory architecture that holds that learning, but how do you actually execute it safely? How do you let an AI take action in a production system without creating chaos?
The answer is the third essential component of Adaptive Software: the Action Architecture.
The Architecture of Action
When I was refactoring the command-mode execution path for D'Stil, I realized this black box approach breaks down entirely when you move from a chat interface to a system that actually modifies state. To truly let my agents rip, they need to be observable and reversible. To accomplish this I broke the execution path into three distinct tiers.
Consider two commands a user might give their agent. One writes data: "Remind me to call Bob later today." The other reads data: "What are my big rocks for the week?" Both are natural language, and both require the system to figure out what the user wants. But one creates a new entity in the database and the other just queries existing ones. In a black-box system, these are completely different code paths. In an Adaptive system, they flow through the exact same pipeline:
The write path and the read path enter the same front door, pass through the same validation, and produce the same structured output. The only difference is what the Worker does at the end. That uniformity is the entire point.
Three Tiers, Three Responsibilities
The pipeline breaks down into three named tiers. This isn't theoretical architecture; it's how I’m structuring it today in my ”Chief of Staff” app, D'Stil. I’m giving here exactly the same thing down to the header comments in the Edge Functions.
Tier 1: The Resolver. The input (user intent) lands here. Its only job is translation. It takes a natural-language message, assembles the full layered context, calls the model, and resolves the user's intent into a structured command. The Resolver never writes to the database. It only figures out what the user wants to do. This separation means you can swap models, tune prompts, or change the context assembly without ever risking a bad write.
Tier 2: The Orchestrator. This is the planner and oversight mechanism. It receives the structured and enriched intent from the Resolver, validates it against the schema, checks authorization, and gates confirmation for destructive actions. It owns the execution plan and the partial-failure policy. But it doesn't actually do the work; it delegates to an executeSingleIntent function that routes the intent through a dispatch seam. Think of it as the supervisor who checks the paperwork before handing the job to the crew.
Tier 3: The Workers. The only tier that touches the database. Workers are divided into two types: Entity Workers handle CRUD operations for specific entities (tasks, goals, events—one entity type each), and Capability Workers handle multi-entity or domain operations (cross-session memory, trip planning, weekly reviews). The beauty of the dispatch seam in the Orchestrator is that new Capability Workers plug in without touching the request handler. The pipeline is extensible at the edges.
The Single Front Door
The most important architectural principle of this pipeline is what I call the Single Front Door: you can only adapt to behavior you can see.
In a traditional system, you might have one API endpoint for user clicks, another for background jobs, and a completely separate integration for your AI features. The system is blind to its own behavior because actions arrive through different doors. In an Adaptive system, everything flows through the same pipeline.
This is what makes Progressive Determinism safe. When the system promotes a pattern from "AI-mediated" to "compiled", the downstream system cannot tell the difference. A compiled rule and an AI guess produce identical OperatorIntent objects. The Workers at the end of the pipeline don't care if the intent was generated by a billion-parameter neural network or a three-line regex. They just execute the intent.
That's what makes compilation safe. The system can graduate a pattern from expensive AI inference to cheap deterministic code, and nothing downstream needs to change.
Total Instrumentation
Because every action flows through the same Single Front Door, the system achieves total instrumentation by default.
Every turn is logged, from the structured intent and the result to the correction the user applied. When the Resolver guesses an intent, the Orchestrator executes it, and the user immediately undoes it or modifies it, that full sequence is preserved as structured data, not buried in a chat transcript.
This is the training data for the Adaptive Memory layer. The system doesn't have to parse a conversation to figure out what went wrong. It has a structured log of the exact intent that failed and the exact correction the user applied. That's the signal that drives learning: the gap between what the system did and what the user wanted.
Making "Let It Rip" Observable and Reversible
The fear of autonomous agents is the fear of irreversible mistakes. We've all seen the demos of an AI agent confidently deleting the wrong database table or sending a hallucinated email to a client.
The Agentic Execution Pipeline solves this by making the architecture safer.
Because the Orchestrator sits between the Resolver and the Workers, it can enforce confirmation gates on destructive actions. Delete something? The pipeline pauses and asks. But even for non-destructive actions, total instrumentation makes the system observable and reversible. If an agent goes off the rails and creates fifty duplicate tasks, you don't have to manually hunt them down. The pipeline logged the exact execution plan and the resulting entity IDs. Reversing the mistake is as simple as rolling back that specific execution block.
This is what makes "let it rip" a viable operating mode. Not because the AI is perfect—it isn't—but because the architecture guarantees you can see everything it did and undo anything that went wrong.
The Complete Picture
Adaptive Software requires three components working together:
| Component | Role | Post |
|---|---|---|
| Progressive Determinism | The learning mechanism. Observes patterns, compiles them from AI-mediated to deterministic code. | Code Over Config |
| Layered Context | The memory architecture. Four layers of state at different densities, with promotion and demotion between them. | Layered Context |
| The Execution Pipeline | The action architecture. Three tiers that make every action observable, reversible, and safe to compile. | This post |
Progressive Determinism tells you what to compile. Layered Context tells you what the system knows. The Execution Pipeline is how it acts, and how it acts safely enough that you can let the other two components do their jobs without fear.
The era of black-box AI execution is ending. If you want systems that adapt to their users, you need an architecture where every action is visible, every correction is captured, and compilation is just a promotion from one intent source to another.
