“The real opportunity is not in picking the best model but instead in building a learning loop on top of models where human capital and token capital compound.”
Satya Nadella, CEO of Microsoft (2026)Platform > Why Dap
Coding is becoming a commodity. Software engineering is not.
Twenty years inside engineering teams taught us where AI compounds and where it destroys value. Dap is what we built when we decided to act on what we saw.
Before the Wave Breaks
We have been building software for twenty years. In that time, every generation of tooling promised to change how software gets built. Some did. Most made the code faster to write and the system harder to understand. Each wave redrew the boundary between what a developer can produce quickly and what requires real engineering judgment.
AI is different. Not because it writes better code than the last generation of tools — it does, dramatically — but because it is the first tool whose productivity scales with how well a system is designed to be understood. A well-architected codebase with explicit context, clean boundaries, and documented decisions is one where AI compounds over time.
A codebase where context lives in people’s heads — which is most codebases that have shipped real software for real customers — is one where AI eventually goes net-negative: it produces plausible-looking code that breaks invariants nobody wrote down.
The teams genuinely winning with AI didn’t just adopt better tools. They made architectural decisions that allowed AI to work at team scale, reliably, and over time. We spent the last several years building Dap on exactly this thesis — first for ourselves, then for the teams we work with. Here is what we decided to solve, and why.
The Problems We All See
When teams start adopting AI at the org level, the problems emerge fast — every developer uses different tools, models, and prompts, with no consistency and no visibility. Symptoms: inconsistent tooling, longer review cycles, cognitive overload. Dap addresses all of them.
Our Convictions
Below the immediate problems are the architectural bets we made. Not features we decided to build — convictions we held before we built anything, that shaped every engineering decision that followed. Some of these weren’t obvious in 2023. Some still aren’t obvious to most teams. We think they will be.
“There isn’t one frontier. There are many. A router mapping request to a collection of models working together to outperform any individual model on many tasks.”
Lin Qiao, CEO of Fireworks AI (2026)
1 . Stay free from the models
Swap models without touching your workflows — your policies, context, and delivery pipeline stay intact
Mix models within the same organization, the same repository, or the same session
Add support for new models as the landscape evolves without rebuilding anything around them
The provider changes when you’re ready. The rules never do.
The AI landscape is changing faster than any organization can track. Pricing shifts. Models improve or regress. Providers change terms. Context windows expand and contract. Companies acquire each other.
When your team’s workflows — prompts, tooling, conventions, evaluation logic — are built inside a single provider’s ecosystem, every one of those changes becomes your problem.
Dap is built so the governance layer is yours. Policies, context architecture, audit trails, toolset configuration: none of these live in the model. They live in Dap, on your infrastructure. The model is a pluggable component. When a better one appears, or a price changes, or a provider shifts its terms, the switch happens in a configuration — not in a six-month migration project.
See how it works
2 . AI costs are shifting. Be ready for the correction.
Configure each agent in a squad with a distinct model — routing is infrastructure, not a manual decision each time
Reserve frontier model capacity for the tasks that actually require it
As model economics shift, your routing configuration adapts — not your codebase
Spend on reasoning. Save on everything else.
4.7x
cheaper than Claude API — per million tokens
Most of what agents do — dependency updates, boilerplate, test coverage, standards enforcement — doesn’t require frontier model reasoning. Routing everything through the most powerful, most expensive model only makes sense while pricing stays subsidized. It won’t.
AI pricing today is a land-grab — providers subsidizing usage to drive adoption. That’s not the long-term price; it is never that low once a technology reaches critical mass and switching costs build up. Teams with routing flexibility will have options when it shifts. Teams anchored to one model won’t.
Dap’s squad architecture lets you assign each agent the model suited to its role: smaller and faster for routine pattern matching, frontier for complex reasoning. The economics compound every session.
See how it works
3 . In an unstable environment, bet on protocols
Dap agents can collaborate with any A2A-compliant external agent — inbound and outbound
Clients with existing agent infrastructure can connect it to Dap without rebuilding either side
As the A2A ecosystem expands, Dap’s interoperability expands with it — no additional integration work required
The agent ecosystem is in a period of maximum instability. New agents, new frameworks, new orchestration models emerge every quarter. Building your architecture around any single platform’s agent model is the same bet as anchoring to one model provider — useful until the platform changes or the ecosystem moves on.
The right bet in an unstable environment is an open standard.
Dap implements the A2A (Agent-to-Agent) protocol natively. Your agents can communicate with any A2A-compliant agent in either direction — inbound or outbound. External agents that your clients or partners run can interact with Dap-governed agents. Dap agents can reach external A2A agents. The interoperability is bidirectional and unlimited in scope.
This is not an integration layer built to work with specific vendors. It is an implementation of an open standard — which means the ecosystem grows as the standard grows, without rebuilding anything on either side.
See how it works
4 . Trust in agents must be earned, not assumed.
Governing-layer policies — which hosts, integrations, and MCP tools it can access, and their permissions — are enforced before it runs, independent of the reviewer
Dap builds a compounding knowledge graph from your repositories, sessions, and failed runs — each agent starts with richer codebase context than the last
Every agent PR receives a confidence score from a panel of independent AI reviewers before it’s eligible for auto-merge
The question isn’t ‘will the agent make a mistake?’ It’s ‘what happens when it does?’
The temptation with autonomous agents is to configure them and step away. The opposite — reviewing every action manually — kills the gain. Neither extreme works.
Trust in agents has to be built. The infrastructure for it has to exist before you extend the autonomy, not after something goes wrong.
That infrastructure has three parts. Governance encodes policies and standards, enforced consistently. Context deepens it: Dap builds a compounding knowledge graph from your repositories, so agents inherit what the system already knows. Verification confirms it: every agent PR runs through a panel of independent AI judges, producing a confidence score that gates auto-merge.
These compound — governance sets the bar, context helps agents meet it, verification confirms they did. Trust earned session by session, not assumed upfront.
See how it works
5 . Bound the blast radius. Scale agent autonomy.
Each session runs in a dedicated compute environment with scoped credentials — destroyed on completion
Preview environments let engineers share live work before it reaches a PR, enabled by the isolation model
Agents can be given full development autonomy — running tests, making commits, exposing ports — because the boundary holds
Security protects your data. Safety protects your codebase.
Most teams think of security as a constraint on what agents can do. We think about it the opposite way.
When each agent session runs in a fully isolated environment — its own compute environment, its own credentials, its own bounded network access, destroyed when the session ends — agents can be given more autonomy, not less. Preview environments are possible because the session is isolated. Port tunneling to share live work is possible because the network is scoped. Taking over a running session mid-flight is safe because no session can affect another.
The boundary is enforced by architecture, not by policy. Policy can be misconfigured. Architecture is structural.
Isolation is not about what agents cannot touch. It is about creating the conditions under which agents can run at full autonomy, with confidence.
See how it works
6 . Own your context engineering.
A unified context layer aggregates your entire engineering workflow before every session — GitHub, your issue tracker, CI, docs, past decisions
Failed sessions sharpen future ones — errors feed back into agent configuration automatically
Context compounds across sessions, repositories, and over time — the platform’s understanding of your codebase deepens with every run
More sessions. Better context. Higher merge rates. More trust. Repeat.
AI’s return in software development is not fixed — it degrades as complexity increases. The variable is how explicit a system’s context is for an agent to use.
Most codebases fail this test over time. Not through negligence — software naturally accumulates implicit context as it evolves. Conventions live in people’s heads. Architecture decisions are buried in old PRs. Bug context is in the issue tracker. Deployment knowledge is in CI configs. Each session starts from scratch, reinventing what the team already knows instead of building on it.
Dap aggregates GitHub, your issue tracker, CI, internal docs, and past sessions into a context layer every session draws from — compounding with every engagement.
Agents improve because context gets richer, not the model. This is context engineering — the architectural work that determines whether AI compounds or stalls. Most teams have not yet started it.
See how it works
We didn’t build Dap out of AI hype. We built it running AI on real client systems every day, seeing exactly where it would break.
Dap is what we use. These are decisions we made before anyone was asking for them, built around before we could prove they’d matter. We’re not chasing the wave — we’re building for teams that want to operate at the front of it.