Skip to main content

Shared context for AI coding agents: the part your agents can't see

· 4 min read
The Align Team
The Align Team
Engineering decision intelligence

Your AI agents have most of the inputs they need. They can read the codebase, the tests, the types, the git history, the open PRs. All of that is deterministic and right there.

What they can't see is why. Why the retry count is three and not five. Why this service owns that table. Why the team walked back the obvious approach six weeks ago. That reasoning lives in a Slack thread, a meeting nobody recorded, a Jira comment, or someone's head. The agent never sees it, so it ships code against decisions it doesn't know exist.

Context engineering is the actual bottleneck​

The capability of frontier models stopped being the limiting factor a while ago. As swyx puts it, context engineering is the new prompt engineering: what matters now is the quality of context the agent operates on, not how clever the model is. Simon Maple frames the same shift as "CI/CD for context", the focus moving from managing code to managing the context around it.

Both are pointing at the same gap. We've gotten good at giving agents the deterministic inputs. We've done almost nothing about the one input that's hardest to capture and most expensive to miss: the decisions.

Why "just put it in CLAUDE.md" isn't enough​

A CLAUDE.md or a rules file is a great start. But it's a static snapshot, hand- maintained, and it captures conventions, not the live stream of decisions your org makes every day. It tells the agent your house style. It doesn't tell the agent that yesterday a different squad decided to deprecate the endpoint this agent is about to build against.

Decisions aren't static config. They happen continuously, across tools, and they change. A useful context layer for agents has to track that, not freeze it.

"Agents can't just ask"​

Here's the thing well-run teams discover. Small teams handle missing context by asking each other, and it works fine. But an agent can't tap a colleague on the shoulder. Even a team with great human communication has to give its agents structured context explicitly, because the agent has no informal channel to fall back on.

So the moment you put agents into a real org, you need the decision context written down and queryable, whether or not your humans needed it before. The graph is the organizational memory agents are missing.

Raw MCP access isn't the answer either​

The tempting shortcut is to point the agent at your tools over MCP and let it read everything. The problem is volume and noise. An agent querying raw Slack is sifting 50,000 unstructured messages to maybe reconstruct one decision, burning tokens and still missing the contradictions.

An agent querying a decision graph gets the opposite: structured decisions, with conflicts and relationships already resolved. One query returns "here's the decision, here's what superseded it, here's the conflict with the payments team", instead of thousands of raw messages it has to interpret.

That's the difference between giving an agent a firehose and giving it an answer.

What this looks like in practice​

Align sits in the context pipeline as the decision source of truth:

  • Engineers capture decisions where they happen (Slack, GitHub, Jira, Teams, Confluence) with an explicit action, so nothing is passively surveilled.
  • Align links them into a graph, tracks how they change, and resolves conflicts.
  • Your agents query the graph through MCP and get structured, current decision context, the deterministic input they were missing.

The payoff is agents that build with your org's decisions instead of around them, and humans who stop discovering the contradiction in code review.

Where to start​

If you're already running coding agents, the fastest way to feel this gap is to ask one to explain a non-obvious design choice in your codebase. It'll guess, because the reasoning was never anywhere it could read. Closing that gap is what Align is for.

Align gives engineering teams and their AI agents one shared, authoritative source of truth for the decisions behind the code. Related reading: Why decisions get lost in Slack and Architecture Decision Records: the complete guide.