An AI Agent Needs Context, Not Just a Connection

Connecting an AI agent to a real tool — through something like the Model Context Protocol, or a plain API — feels like the milestone. You run a query through it, it works, you celebrate. Then it confidently writes to the wrong field, invents a status that doesn’t exist, and emits a malformed call, and you realize the connection was the easy 10%. The other 90% is context engineering: teaching the agent how your system actually works.

A connection is not comprehension

Most enterprise tools are a standard product wearing a decade of local customization. Take an issue tracker that, out of the box, has a simple hierarchy — and then imagine an instance with a five-level hierarchy spread across separate projects, thousands of custom fields, and conditional rules like “only fill this field when that other field is off-track.”

Plug an agent into that and, with no other guidance, it falls back to what it “knows” — the vendor’s default, stock assumptions about how the product works. It uses the generic field names. It assumes the simple hierarchy. It’s confidently, fluently wrong, because the gap between the standard product and your configured product is exactly the gap it can’t see.

Encode the domain model as durable context

The fix isn’t a smarter model; it’s writing the system’s reality down where the agent will read it. Steering and context files that capture:

• the hierarchy and the linking rules — which field actually joins a child to its parent, because in a customized system it’s rarely the obvious one;
• the workflows — the valid statuses and the legal transitions between them, so it doesn’t try to jump to a state that doesn’t exist;
• the field map — the handful of custom fields that matter, by their real identifiers, with their types;
• the conditional logic — the “only when” rules that a human learns by being yelled at in code review.

This isn’t documentation for humans. It’s the model the agent reasons from. And curation matters: a system with thousands of custom fields doesn’t need all of them dumped into context — it needs the curated dozen that actually come up, or you’ve just traded “no context” for “context it can’t find the signal in.”

Cache the stable, fetch the volatile

The pattern that makes this both correct and affordable is classifying data by how often it changes:

• Structural facts — the projects, the fields, the workflows, the issue types. These almost never change. Fetch them once, cache them locally, and read from the cache forever after.
• Operational data — the actual records, their current status, who’s assigned right now. This is volatile. Always fetch it live; never cache it.
• The middle tier — things like sprint or board data. Cache-first, fetch on a miss.

Get this classification right and the agent stops re-deriving the unchanging shape of your system on every single task.

Caching is also how you survive rate limits

That isn’t just a tidiness win. Live calls cost something, and real systems meter them — exceed a daily budget and you get throttled or cut off. An agent that re-discovers the entire field schema before every action will burn through its allowance on questions whose answers never change. Reading cached context for the stable stuff and spending live calls only on genuinely live questions is what keeps it under the ceiling.

A couple of disciplines make the cache trustworthy: append to it incrementally rather than re-fetching everything, and when cached context disagrees with what the live system returns, report the mismatch and stop — don’t let the agent silently “correct” itself, because a silent auto-correct is how a stale assumption becomes a confident wrong write.

Connecting an agent tells it where the system is. Context tells it what the system is. Only one of those keeps it from doing damage.

Treat agent config as code

The steering and context files that encode all this are not scratch notes. They’re versioned, reviewed, and shared like any other source — because they are source; they’re the part that determines whether the agent is an asset or a liability. The teams getting real value out of agents keep their skills and steering in repos, reuse them across projects, and review changes to them as carefully as they’d review the code those agents touch. The capability lives in the config.

The connection is the part you can demo in an afternoon. The context is the part that makes the agent something you’d actually trust against a real system. I think about this the same way I think about keeping AI honest while moving fast — the guardrails are the product. If you’re wiring an agent into a gnarly internal system and it’s confidently wrong, I’m happy to talk through it.