AI agents can reach your systems; that still doesn’t mean they can decide well
A lot of teams start with the same assumption: if an AI agent can just get into enough systems, it will become useful. Give it database access, connect the file store, wire up Slack, maybe toss in the CRM for good measure, and the thing should start pulling its weight. In practice, that’s where the optimism gets a little bruised.
The agent can often do the task. It can read the record, fetch the document, find the message, And even take the action. The problem is that it may still pick the wrong action. It sees a customer account and issues a refund when the policy says to request a replacement first. It finds an internal doc and treats an outdated process as current. It posts an answer in the wrong channel because it has access to the chat tool but no sense of where that answer belongs. The plumbing works. The judgment doesn’t.
That gap matters because access and decision-making are different problems. Access is mostly about permissions, authentication, and routing. Can the agent call the API? Can it read the folder? Can it write the row? Those are solvable engineering tasks, and they’re getting easier all the time. Decision-making lives elsewhere. A real product workflow usually has exceptions, thresholds, approvals, stale state, partial failures, and rules that depend on history. A system can be open to the agent and still be a terrible place for it to make an autonomous choice.
Reach is easy to buy. Judgment has to be designed.
This is where a lot of agent projects drift off course. Teams add more connectors and expect better results, but wider access often just gives the model more places to be confidently wrong. A broader search path can surface conflicting records. A direct line into the ticketing system can expose old notes that look current. A connection to shared docs can pull in a policy draft that never got replaced. The model isn’t broken in some dramatic way. It’s doing what models do when the surrounding information is fuzzy: it fills in the blanks. That’s fine when you’re drafting an email. It’s less charming when the agent is changing a billing record.
Real workflows punish guesswork. Suppose an AI agent is helping with customer support. It can read the order database, see the last three tickets, and check the refund tool. Great. But if it doesn’t know that a partial refund was already issued two hours ago, or that chargebacks above a certain amount need approval, or that one product line has a different return rule, it may still take a path that looks reasonable and ends in cleanup work for a person. The same pattern shows up in ops, finance, sales, and internal tools. The agent had access. It still lacked the context needed to choose well.
That’s the central idea in this article: better results come from treating context as something you design, not something you hope the model infers. Context engineering is the practical work of deciding what the agent should know, what it should ignore, what it can act on, and when it needs to stop and ask. If that sounds less glamorous than “connect everything,” well, yes. It’s also a lot closer to shipping something that doesn’t create fresh tickets for the team every morning.
The next section gets concrete about what context actually includes, because that’s where the real design work starts. Business rules, current state, recent history, task intent. Leave any of those out, and an agent can still look capable while making surprisingly expensive mistakes.
What context actually means for an AI agent
” That’s where context comes in. In practice, context is the slice of information that changes the decision. Not the entire company wiki. Not every message ever sent. Just the facts, rules, and history that affect what the agent should do right now.
An agent with access can still make the wrong move if it can’t tell which facts matter for this decision.
Think about context in layers. The first layer is business rules: refund thresholds, approval limits, escalation paths, policy exceptions, and the business outcome you actually want. An agent can have permission to refund a customer and still do the wrong thing if it doesn’t know that refunds over $200 need review, that subscription cancellations within seven days get a different treatment, or that some accounts are exempt because of a contract clause. The tool worked. The judgment didn’t.
The second layer is current system state. That sounds obvious until you watch a bot act on stale data with total confidence. A support agent might see an order marked “pending” in one system, then cancel a shipment that already left the warehouse ten minutes ago. A finance bot might approve a duplicate payment because it never checked whether the invoice was already settled. The permissions were fine. The state was wrong. In OpenAI’s conversation state guidance, this problem shows up plainly: if the model doesn’t have an explicit, current picture of the task, it can’t keep its decisions grounded in reality.
Then there’s recent history, which trips up agents more often than people expect. An agent should know what it already did, what a human already approved, and what happened in the last few turns of the workflow. Without that, it may repeat an action, undo a prior step, or ask the same question three times like an intern who missed the meeting and is pretending that was part of the plan. A customer support agent might resend a password reset link after the user already clicked the first one. A billing agent might re-open a ticket that a human just closed. A procurement assistant might file the same request twice because it didn’t retain the earlier approval.
The last layer is intent. What’s the actual job here? “Process this request” is too vague. “ The agent needs to know whether the goal is speed, safety, customer retention, cost control, or some mix of the four. That intent changes the decision. If a customer asks to cancel, do you offer a retention discount, stop immediately, or route to a specialist? The right move depends on the objective behind the request, not just the request text itself.
Context is easy to misunderstand because people treat it like a bigger pile of data. It isn’t. More data often makes things worse. If you hand an agent twenty documents, but only one of them is current and only one of them changes the outcome, you’ve just given it more chances to be confused. Good context is selective. It contains the facts that move the decision from one branch to another.
That’s why exception cases matter so much. A rule like “auto-approve expense reports under $100” sounds tidy until the agent sees a report for $92 that was submitted after the deadline, by someone on a restricted project, with a vendor that needs manual review. If it doesn’t know the exceptions, it may apply the rule too broadly and still be technically obedient, which is a lovely way to create cleanup work for someone else.
The same thing happens when an agent ignores prior actions. Suppose a sales assistant is told to send a discount code to a lead. If the lead already redeemed one yesterday, the agent should probably stop, ask for a different offer, or check policy before sending another. Without that context, it may follow the instruction literally and create a problem that looks small until finance notices the margin.
This is where retrieval rules matter. If the agent is allowed to pull in documents, tickets, emails, or uploads, you need a rule for what counts as source material, how recent it must be, and what to do when sources disagree. The goal isn’t to retrieve more. It’s to retrieve the right bits. Anthropic’s guide to effective context engineering for AI agents makes a useful point here: the surrounding information has to be shaped so the model can use it without guessing. That usually means filtering stale references, preferring authoritative sources, and rejecting content that conflicts with the active task.
It also means treating untrusted text with care. If an email, document, or support ticket contains instructions directed at the agent, those instructions are still just content. They aren’t policy. OWASP’s LLM prompt injection prevention cheat sheet is worth reading for that reason alone.
” Business rules. Current state. Recent history. Task intent. Exception handling. Approval thresholds. Expected outcome. Miss one of those, and the agent can still complete the task in a literal sense while getting the real answer wrong. Which is a very efficient way to make a system look busy and a team look tired.
The good news is that this can be designed. Once you can name the layers, you can start deciding which ones belong in the agent’s working set and which ones need tighter control. That’s where the engineering part begins.
Treat context like infrastructure, not prompt fluff
Once an agent can read the right records and call the right tools, the next failure usually isn’t access. It’s drift. The instructions that seemed crisp in week one turn fuzzy by week six. Someone edits a prompt in the UI, another person copies it into a notebook, and suddenly the agent is making different calls in the same workflow because nobody knows which version is live. That’s not an AI problem so much as a config problem with a very expensive autocomplete attached.
The fix is boring in the best way. Treat the agent’s operating rules like code. Put them in version control. Review changes. Test them against real examples from your agent workflows. If a rule says, “Refunds above $200 need approval,” that sentence should live somewhere reviewable, not in a pasted blob of prompt text that gets edited after a demo when everyone’s feeling brave. Versioned instructions let you answer basic questions later: what did the agent know, when did it know it, and who changed the rule that sent it off course?
If the agent can’t justify the step, it probably shouldn’t take the step.
That same mindset should apply to permissions. An agent doesn’t just need access to a database or chat app. It needs a clear map of what it may do, what it may ask for, and what it should never attempt on its own. This is where a lot of AI automation goes sideways. Teams give the model broad tool access, then hope the prompt will quietly prevent bad behavior. That’s not a control system. That’s wishful thinking with a logs tab.
Make the boundary explicit. Let the agent read order history, but require approval before it changes a billing plan. Let it draft a support reply, but block it from sending a compensation promise without a person signing off. Let it query inventory, but don’t let it create a purchase order unless a separate rule says the stock threshold and vendor status are both satisfied. The wording matters less than the structure: allowed, conditional, forbidden. The sharper that line is, the less the agent has to infer from vibes.
The same goes for retrieval. A model that can pull every document it touches still doesn’t know which document should win. That’s how stale policy pages, old tickets, and contradictory notes end up in the context window at the same time, all talking over each other like a group chat nobody asked for. Retrieval rules need to say what sources are acceptable, how recent they must be, and which sources outrank the rest. Current policy docs can outrank archived docs. The live record in the app can outrank a summary in the ticketing system. A cached note from last month probably shouldn’t override the source of truth unless the business has a very good reason for it.
This is where some teams get tangled up. They think more retrieval means better judgment. It doesn’t. The trick is selecting the smallest set of evidence that changes the decision. If the agent is deciding whether to resend a receipt, It may only need the latest transaction state and the current refund policy. Pulling the entire customer history just creates noise unless a recent escalation or fraud flag changes the decision. Good retrieval rules narrow the search before the model starts improvising. Anthropic’s MCP documentation, OpenAI’s agent builder safety guidance, and Microsoft’s agent framework safety guidance all reflect that basic pattern: control what gets exposed, and be deliberate about what the agent is allowed to use.
Clear fallback paths matter just as much. If the agent can’t find the order number, it should ask for it. If two policy sources conflict, it should stop and surface the conflict instead of picking the one that sounds nicer. If the action would change money, access, or legal status and the context is incomplete, it should hand off to a person or end the workflow. That’s not failure. That’s the difference between a useful system and an expensive guessing machine.
A good fallback path gives the agent a place to go when confidence drops. Sometimes that means asking a narrower question. Sometimes it means escalating with a short summary of what it found and what it couldn’t confirm. Sometimes it means doing nothing, which is annoyingly underrated. In real operations, “pause and ask” beats “make a confident mess” more often than people admit in demos.
Good context design also makes postmortems less painful. When an agent sends the wrong email or updates the wrong record, you want to see the rule version, the permissions it checked, the documents it retrieved, and the reason it stopped or continued. That trail does two jobs at once. It helps you fix the incident, and it tells you whether the agent actually understood the situation or just matched a pattern that looked close enough. The best systems leave a clean paper trail without forcing everyone to become a detective.
If you build context this way, the agent feels less magical and more dependable. That may sound like a downgrade to a demo, but it’s a win in production. Demos can tolerate a little chaos. Shipping systems can’t.
The real test: can the agent explain why it acted?
After all the work of treating context like infrastructure, there’s a simple question left on the table. If the agent makes a choice, can it explain that choice in plain language?
That sounds almost too basic, which is usually a good sign. A lot of bad automation survives because it seems clever in a demo and only gets weird once it touches real data. An agent can have read access to the CRM, write access to the ticketing system, And a cheerful little toolbox full of actions. None of that tells you whether it understands the business rules behind the action it just took. Access grows fast. Judgment doesn’t. Judgment depends on the quality of the instructions, history, state, and fallback paths around the model, which means you’ve to engineer that context on purpose.
A useful readiness test is embarrassingly plain: ask the agent why it picked one action instead of another. Not in model-speak. In human language. If it replied, “I closed the ticket because the user asked for a refund and the order was 3 days old, which falls inside policy A, and the account had no fraud flags,” you’re at least dealing with something that has a traceable chain of reasoning. If it says, “I did the thing because I had access to the thing,” you’ve got a very confident intern with a credentialed keycard. That might be fine for a narrow workflow. It isn’t fine for autonomy.
If an agent can’t explain its choice without hand-waving, it probably doesn’t have enough context to make that choice alone.
This is where a lot of teams get tripped up. They measure the wrong part of the system. Connector count looks impressive in a roadmap review, and yes, it feels nice to say the agent can reach Gmail, Salesforce, Slack, the database, and seven other tools nobody has time to remember. But tool coverage isn’t the same as decision quality. For LLM agents, the harder question is whether the available context lets them make a decision that a human would accept after the fact. If the answer is no, more connectors just mean more places for a wrong guess to land.
That’s also why error recovery matters so much. A decent agent will be wrong sometimes. The difference between a tolerable mistake and a disaster is often what happens next. Does it stop and ask? Does it revert the change? Does it flag uncertainty clearly? Or does it barrel ahead because the prompt said to be helpful, which is a charming trait in a support rep and a terrible one in software?
Teams that care about developer productivity should measure this stuff directly. Track how often the agent escalates instead of guessing. Check whether its explanations match the actual rule that governed the action. Look at how many bad decisions were caught by fallback logic versus cleaned up manually after the fact. Those numbers tell you more than a dashboard full of tool icons ever will.
The practical standard is simple. An agent is getting close to autonomy when it can describe, in plain language, what it knew, what rule it applied, what it was unsure about, and why it still chose to act. Until then, keep the guardrails on. The point isn’t to give LLM agents more buttons to press.
