Application Context Engineering
Give coding agents the context they need for each change.
A coding agent can write good code and still get the change wrong, because what makes a change right is usually written down somewhere it never looks. For one ordinary request, that context comes from three places.
The ticket says what to build
“Expense claims need a second approver.”
This is usually all the agent is given.
The architecture says where it fits
“Approvals live in the Approval Service, and every decision writes to the audit log.”
Without it, the agent adds the check wherever the ticket's screen happens to be.
The policy says what must pass
“No one approves their own claim.”
Without it, the code works in the demo and fails the audit.
ACE keeps all three linked in an application context layer, a persistent and up to date body of knowledge about the application that agents query while they work. It's built from business requirements, enterprise standards, compliance policies and domain knowledge, along with the application's own code.
Application Context Engineering is the discipline of building that layer, handing each change the slice it needs, and keeping it true.
Why it matters
The model is the routing algorithm, and nobody gave it the map.
A route is only as good as what the map knows about the roads a truck can actually use, and a brilliant algorithm working from a bad map will confidently send the truck somewhere it can't go. Coding agents are the same. Give a capable agent your repo and a feature request, and within minutes it will write something that compiles, calls an API that was retired last year, ignores the auth pattern every other service follows, and breaks a rule nobody wrote down.
The reason is that our SDLC tools record what happened but not why. Git knows every line that changed and Jira knows every ticket that closed, while the reasons live in Slack threads, PR comments and people's heads. A person who doesn't know why something is the way it is will usually ask around, but an agent will usually just pick an answer and keep going. Each wrong pick costs a review cycle or a rework loop, and on a large application those add up to weeks.
What your coding agent actually sees
Micro tools see one feature. A macro framework sees the whole application.
ACE: the enterprise grade macro framework for Application Context Engineering
The application context graph
Three types of context, so agents know what exists, what's allowed, and what happened and why.
Structural
What exists and how it connects: the application profile, capabilities and features, design, architecture, specs, policies, decisions and pull requests, plus the links between them.
In ExpenseFlow: the approval threshold requirement links to the Approval Service, its ADR, two APIs and the pull requests that built them.
Operational
How work gets done and what's allowed: lifecycle states, approvals, governance decisions, exception criteria and the logic that governs the work.
In ExpenseFlow: a change to approval logic needs architect sign off and has to pass the audit logging policy check.
Historical
What happened and why: precedents from the code and documents, what's done, what's incomplete, what worked, and where the application stands today.
In ExpenseFlow: an exception approved last quarter, with who approved it and why, surfaces the next time an agent touches that code.
What feeds it
Six inputs, some from outside the application and some produced by the SDLC itself.
1 · External context
Business goals, enterprise and compliance standards, coding practices and agent skills.
2 · Runtime context
The application profile, capabilities, features, architecture and current state.
3 · Application team memory
Who executed and approved each task, plus learnings, decisions, exceptions and attestations.
4 · Human collaboration and attestation
Reviews and sign offs from the people who own the application, wherever a team wants them.
5 · AI enrichment
Baselines reverse engineered from code, suggested links, gap analysis and summaries.
6 · Application artifacts
Code, specs, designs, ADRs, tests, pipelines and pull requests, the ground truth drift is checked against.
What it does
Four critical components, and running all four well is the discipline.
Cataloging
The context and its state over time, so anyone can see what's true now and how it got that way.
Curation
Turning agent drafts and tribal knowledge into certified context agents can rely on.
Engineering
Measuring where agents still go wrong and fixing the context behind it until work hits a 90% accuracy threshold.
Retrieval
The right slice for each task through MCP, an SDK or a sandbox, with tools to pull in more, never the whole context at once.
What it isn't
Because the idea is new, people map it onto something they already have.
Not a prompt
A prompt is assembled for one request and thrown away, while the layer persists and is governed.
Not a rules file
Rules files are written by hand for one harness, and they rarely say why a rule exists.
Not an index over the repo
Retrieval finds text that looks similar, while the layer holds what the code is supposed to do.
Not static documentation
It stays in sync with every input and with the code, and things that get read every day get fixed.
Not a data catalog
Those describe data; this is a semantic graph of the application, which consumes data semantic layers as inputs.
Not tied to one model
The same context serves every agent, whichever model or harness it runs on.
Objections worth answering
Won't the models get smart enough to make this unnecessary?
Smarter models guess better, but no amount of intelligence lets a model know what your team decided last quarter, or why.
Documentation always rots, so why would this be different?
Static documentation rots. This is kept in sync with its inputs and the code, and agents read it on every task, so errors get noticed and fixed.
Isn't this too much overhead for a small app?
Sometimes it is. The threshold is when more than one agent or developer works on the app, or when the app will outlive the people who wrote it.
We already write specs. Why do we need more?
Keep writing them. Specs are inputs, and the context graph is what relates them to each other, to the code and to the decisions behind them.
Bring one challenge to a 30 minute working session.
In 30 minutes, we'll walk through a relevant example and show how ACE could help your team tackle it.
Book a 30 Minute Working SessionRead the white paper