Context vs contracts

I know the reflex.

An agent does the thing almost right. It understands the request, finds the relevant files, makes a reasonable call, then misses one constraint that mattered. So I open the system prompt and add another paragraph.

It feels responsible. I have given the agent more of the world. Surely it will make the better choice next time.

Sometimes it does.

Sometimes I have just hidden a production requirement inside a conversation-shaped pile of text. The next agent gets a different slice of history. A future version weighs the instructions differently. The important sentence is still there, technically. It has simply become one sentence among hundreds.

That is the fight I keep seeing in agent work now.

Team Context says an agent fails because it does not know enough. Give it the history, the customer details, the architecture notes, the screenshots, the decisions that happened three weeks ago, and the weird exception somebody explained in a chat. A capable model with thin context is a clever new hire dropped into a meeting halfway through.

Team Contracts says this is how systems become unmanageable. If every important rule is prose in a giant prompt, nobody can tell which rule applies, whether it was followed, or what changed when it fails. Put the expectation in a test, a schema, a permission boundary, a checklist, or a source-of-truth file. Make it visible. Make it reviewable.

Both camps are right. They are just trying to solve two different problems.

The case for context is stronger than its critics admit.

A contract cannot tell an agent why a decision is sensitive this week. It cannot explain that a customer is upset, that the team is trying to preserve a particular relationship, or that a technical option which looks cheaper is a trap because of something that happened last quarter. Those are judgment calls. They live in the situation.

I have watched agents make technically clean decisions that were operationally wrong because they were missing one piece of history. Not because the model could not reason. Because it was reasoning from a map with a piece torn off.

This is why the recent turn toward "context engineering" is useful. The problem is not finding a magic sentence for the prompt. It is deciding what information a model needs right now, in what form, and how much of it it can actually use. Anthropic describes that shift well: the work is broader than prompt wording. It is about configuring the context that gives the model a real chance of producing the behavior you want.

Good context is not a dump.

It is the current objective, the relevant state, the constraints that matter in this situation, and the evidence needed to make the next decision. A good handoff note can save hours. A clear explanation of the real trade-off can keep an agent from optimizing the wrong thing with great confidence.

There is also a human reason to prefer it. Work is full of details nobody thought to formalize because they seemed obvious to the people in the room. Context lets an agent join the room before we have finished turning every instinct into a process.

That matters. A team that refuses to give agents situational context will get agents that look reliable only on the narrow cases the team managed to predict.

But the other side wins a different argument.

Imagine an agent preparing a customer migration. The team wants it to move quickly, but one account has a contractual blackout period and no one has delegated the authority to override it.

You could bury that detail in a long project summary: "Account A is sensitive. Be careful around the blackout." The agent may read it. It may also treat it as one soft consideration among dozens.

Or you can make the rule part of the work itself. The migration state includes the account's blackout window. The run cannot move into the execution stage without an explicit override from the owner. The system records who approved it and why.

Nothing was wrong with the agent's calendar. The failure was treating a hard boundary as background knowledge.

I do not want an agent to act because it happened to remember, somewhere inside a long prompt, that an exception matters. I want a rule it has to meet.

A contract can say: no production migration during a blackout window unless the designated owner approves the exception. It defines a state, an owner, and a response to failure. The context explains why the account is sensitive. The contract prevents a reasonable-sounding model from deciding that "probably fine" is good enough.

"This account has a blackout period" is a fact. It may sit in context and help an agent understand the case. "Stop the run unless the designated owner approves an override" is a contract. It defines a state, an owner, and a response to failure. One sentence describes a constraint. The other creates a system that can notice when the constraint is about to be broken.

This is where long-lived agent setups get strange. We keep putting rules into memory because memory feels personal. Then, months later, we discover that we have built a private constitution out of tiny sentences that no one can test.

A behavior is not safer because it is written down. It is safer when we can inspect it.

Can we see the rule? Can we tell when it applies? Can we change it without rewriting a biography? Can we check whether the system followed it? Can a new person understand it without reading six months of chat history?

If the answer is no, the rule is probably in the wrong place.

This is why skills, playbooks, schemas, tests, and permission boundaries matter. They turn repeated expectations into artifacts. They are not glamorous. They are the boring parts around the model that stop the same mistake becoming a tradition.

OpenAI recently made a practical version of the same point in its guidance on evaluating agent skills: use real failures to drive coverage, and turn a manual fix into a test when the rule is deterministic. That is the move. Do not merely tell the agent to "be careful" next time. Decide whether the failure describes a repeatable expectation. If it does, promote it.

The mistake is deciding that context and contracts compete for the same job.

They do not.

Context is for judgment. Contracts are for repeatability.

Give an agent context when it has to understand what is unusual about this case. Give it a contract when you need the same condition to survive a new session, a new model, a new teammate, or a rushed late afternoon.

A useful test is brutally simple: how often am I explaining this?

If I am explaining that a client has a particular sensitivity because of a recent event, that belongs in context. It may change next week. If I am explaining, for the fifth time, that no public action happens without approval, I do not have a context problem. I have failed to encode authority.

The same applies to technical work.

An agent may need a recent incident report to understand why latency matters more than feature scope today. That is context. But if the deployment must pass a particular check before it can reach production, that belongs in the pipeline. The incident report helps it choose. The check stops it from improvising a rule that should not be improvised.

This does not mean every recurring sentence deserves a test. Some things are too subjective. "Use good judgment" is not a useful contract. "Keep customer data in approved systems, retain it for the agreed period, and stop when authority is missing" can be partly checked, partly reviewed, and partly escalated.

That is good enough. A contract does not need to eliminate judgment. It needs to make the boundary between judgment and routine visible.

When an agent keeps missing something, I would ask five questions before adding another paragraph to its prompt.

Those questions do not remove the work. They move it to the right place.

A mature agent system will probably have more explicit artifacts than its early prototype. That is not bureaucracy winning. It is the system learning which decisions deserve to outlive a single conversation.

I still reach for more context first.

It is fast. It feels humane. I can explain the nuance in the way I would explain it to a person sitting beside me. And sometimes that is exactly what the work needs.

But I am trying to notice the moment when I am repeating myself.

The third reminder is usually not a reminder problem. It is a design problem.

If I have to explain the same rule every week, it is not context anymore. It is a missing contract.

The next debate is Skills vs Memory: what should an agent learn about a person, and what should live in an explicit procedure instead?