Three layers of agent operating systems
A coding agent pattern that's about to show up everywhere
The “coding agent for everything” thesis is compelling: give an AI a filesystem and a Python interpreter, and it can tackle problems that confound traditional software. The agent reads context from files, writes code to solve problems, and persists state across sessions.
This works. We’ve built a finance platform around it. But running it in production revealed what the thesis leaves out: coding agents alone can’t handle high-volume, regulated work. Two additional layers made it work:
- Infrastructure to process unstructured data at scale
- Workflow and review interfaces to run processes repeatably
Use case-specific agent operating systems can’t be individual sandboxes like Claude Code. Without this scaffolding, the filesystem pattern fails under real-world constraints.
---
Why We Built This Way
We started building accounting automation in 2024. The problem we were solving forced a particular architecture: unstructured documents coming in (PDFs, emails, bank feeds), structured data going out (ERPs, general ledgers). Standard finance operations, but messy in practice.
The system needed to be composable because the inputs were unpredictable. Every customer had different document formats, different GL schemas, different vendor naming conventions. We couldn’t hardcode the logic.
In the last month, we integrated a coding agent with a harness and filesystem. We moved core infrastructure to a project-based filesystem that controls what context the agent can access. The fit was natural. The agent could read ingested documents, write code to transform them, and persist its reasoning. It worked because of the infrastructure we’d already built.
That infrastructure turned out to be weight-bearing. Without it, the coding agent couldn’t operate at scale. With it, the agent became genuinely powerful.
---
The Three Layers
Layer 1: Structured Data Infrastructure
Here’s the problem with “just give the agent a filesystem”: if you’re processing 20,000 invoices per month, you can’t dump them all into a directory structure and expect an agent to work with them efficiently.
The raw volume breaks the context window. The variety breaks pattern matching. If your agent is reading raw documents just to find basic fields, you’re burning expensive inference on trivial work.
You need infrastructure that uses LLMs to enforce structured outputs on unstructured inputs. This is extraction, not reasoning. The LLM doesn’t decide what the data means, it just forces chaos into schema: turning PDFs, emails, and spreadsheets into normalized, queryable tables.
This separates extraction from reasoning. The extraction layer handles repetitive work at scale. It produces clean, structured data that the coding agent can query flexibly without drowning in noise.
What breaks without this layer: The agent’s context fills with raw documents. It spends tokens on parsing instead of reasoning. Latency becomes unacceptable. Cost spirals.
---
Layer 2: The Coding Agent
The coding agent operates on top of structured data. It’s good at three things:
1. Building the environment.
When a new client onboards, the agent scaffolds their operational setup: Standard Operating Procedures (SOPs), vendor categorization rules, reconciliation logic. It reads existing documentation, asks clarifying questions, writes configuration files, and generates the initial ruleset.
This is a huge unlock. Traditional enterprise software requires a human consultant to do this setup, which takes months and costs tens of thousands of dollars. The agent does it in an afternoon by working collaboratively with the process expert to encode their knowledge into the file system.
2. Handling exceptions.
Structured workflows (more on this in Layer 3) handle the 80% case. The coding agent handles the 20%: unusual document formats, one-off data migrations, edge cases that don’t fit the standard process. It writes custom scripts, tests them, and integrates data back into the system.
Without this flexibility, you’d need to escalate every exception to engineering or reject the work entirely. The agent turns exceptions into solvable problems.
3. Ad-hoc analysis.
Once project-specific structured data exists, the agent becomes a natural language interface to it. If you need to create a custom report, export data in a specific format, or investigate an anomaly, the agent writes SQL or Python to pull exactly what you need without waiting for someone to build a feature.
This is where the “coding agent as OS” thesis really shines. You’re not constrained by the software vendor’s prebuilt reports and workflows. You have direct, flexible access to your own data.
What breaks without this layer: The system becomes brittle. Every edge case requires developer customization. Every new customer need requires a product roadmap discussion. You lose the adaptability that makes AI-native software different.
---
Layer 3: Deterministic Workflows
Here’s what the “coding agent for everything” framing misses: you don’t want an agent improvising when you’re booking $2M to a general ledger across thousands of transactions.
Daily operations like invoice matching, approval routing, and posting to the ERP happen in purpose-built interfaces with event-driven workflows. The process is deterministic, auditable, and includes human checkpoints where they matter.
This is load-bearing architecture rather than limitation.
In domains like accounting, the process by which a result is derived matters as much as the result. If an auditor asks why a transaction was categorized a certain way, you need to show them a rule, not a sampling of LLM output. You need to prove the logic is consistent, not just that it’s usually correct.
A coding agent generating novel logic for each transaction creates variability. Variability breaks auditability. Auditability is non-negotiable in accounting, healthcare, legal, or any other domain where mistakes have regulatory consequences.
The structured workflows are also where throughput happens. An agent handling 500 invoices per day by writing fresh Python for each one would be slow, expensive, and unpredictable. Event-driven pipelines with clear rules handle the volume efficiently. The agent helped design the flow, but the flow itself runs without the agent’s ongoing involvement.
What breaks without this layer: Cost and latency make high-volume operations impractical. Auditability vanishes. Human reviewers can’t keep up because every transaction looks different. Trust erodes.
---
The Human as a Tool
Most agent hype focuses on removing humans from processes. In consequential domains, this is backwards.
The right pattern is to treat the human as a tool the agent can invoke. When the reconciliation logic hits a fuzzy vendor match that’s not in its instructions, the agent doesn’t crash or guess. It pauses, surfaces the ambiguity, and asks:
“This looks like Amazon Web Services, but the address is Dublin and the amount is 15% higher than usual. Should I proceed?”
The human confirms. The agent resumes.
This is different from traditional “human in the loop” design, where humans are exception handlers. Here, invoking the human is part of the agent’s normal operation. The agent routes judgment calls to the human the same way it would query a database or call an API.
The human provides judgment where judgment matters: validating assumptions, catching anomalies, approving anything consequential. The agent provides speed and consistency where those matter: processing volume, applying rules, surfacing what needs review.
This isn’t a fourth layer—it’s orthogonal to the architecture. It’s about control flow. The agent can invoke the human from any layer.
---
Why This Architecture is Hard to Retrofit
If this pattern is effective, why isn’t everyone doing it?
Legacy software vendors and AI-first companies face architectural lock-in.
Their AI stack is built for retrieve → answer → forget. Moving to stateful work loops and filesystems means rewriting the data model, the API layer, and the UX.
They also sold customers on “read-only” AI. Giving an agent write access to the general ledger requires rethinking the security model and permissions system from scratch.
Horizontal agent companies face the application layer problem.
A general-purpose coding agent can learn domain knowledge. You can give it GAAP documentation, explain three-way matching, teach it intercompany transfers. The knowledge can live in the filesystem.
But knowledge alone doesn’t create a usable application. The agent needs structured workflows to express that knowledge in a way teams can actually use to complete work. It needs purpose-built interfaces for invoice approval, reconciliation review, and GL posting, not just a chat window where users describe what they want done.
Domain expertise without workflow infrastructure is just an expensive consultant with no tools.
---
What This Means for Vertical AI
The winning AI Application companies won’t be chatbots over databases or coding agents with filesystem access. They’ll be operating systems with three weight-bearing layers:
1. Structured data infrastructure to handle volume, normalize inputs, and update context.
2. Coding agents to provide flexibility, handle exceptions, and adapt to customer-specific needs.
3. Deterministic workflows and purpose-built interfaces to deliver throughput, audit-ability, and consistency where they’re non-negotiable.
The coding agent is the architect and analyst. The structured workflows are the assembly line. The human is the supervisor with final authority.
Get all three right, and you have something that actually works in production.
Skimp on any one, and you’re either too rigid (traditional software), too expensive (agents all the way down), or too untrustworthy (LLM output without guardrails).