Most agent drift begins long before a system fails.
“The most basic of all human needs is the need to understand and be understood. The best way to understand people is to listen to them.”
— Ralph G. Nichols
Strong companies aren’t defined by perfect execution.
They’re defined by clear responsibility and explicit communication — especially when things don’t go according to plan.
People are probabilistic.
They perform best when the job is clear before performance is evaluated.
So why wouldn’t we apply the same logic to the AI systems we design to interact with us daily?
Probabilistic humans.
Probabilistic LLMs.
A system should understand its job before it tries to optimize it.
If you’ve ever watched an agent slowly drift — not fail, not hallucinate, just subtly expand — you’ve seen what happens when that sequence is reversed.
Optimization without a clear job.
Before refining prompts, before debating wording, you need to decide what the agent is actually responsible for.
That’s what a project charter does.
In Responsibility Engineering, that clarity lives in two artifacts: a Responsibility Problem Statement and a Responsibility Success Profile.
Together, they define what the system is designed to do — and just as importantly, what it must refuse.
In this article, you’ll see how a Responsibility Problem Statement and Responsibility Success Profile function like a project charter.
Start With One Job
For example, imagine you’re building a curriculum review agent.
Its job sounds simple:
Surface structural inconsistencies created during iteration and flag friction that signals a design decision is required.
Clear.
But without a charter, that role can quietly expand.
It can move from flagging to advising.
From detecting to redesigning.
From surfacing to optimizing.
That expansion feels helpful.
Until it isn’t.
Notice the Drift Pattern
If you’ve ever attached a toolkit, refined a few terms, and asked a model, “Does anything else need to change?” you’ve probably seen something like this:
“Escalation Gaps” should be renamed to “Escalation Triggers” to align with PRS clause language.
Helpful.
But then:
It misses places where old terminology still appears.
It suggests structural improvements instead of just flagging inconsistencies.
Nothing dramatic. Nothing obviously wrong.
But the role shifts.
That’s usually the signal: you never declared what the agent is allowed to be responsible for.
Declare the Job Before It Expands
When you scope the job clearly, you’ll often discover you were asking the agent to do more than one thing.
For example:
Reduce learner friction.
Ensure term consistency.
Manage cross-toolkit cohesion.
Those are related. They are not the same job. And they don’t require the same posture.
One invites advising.
One invites auditing.
One invites managing change.
Put them together, and the agent starts expanding.
Multiple responsibilities sound thorough. They create drift.
Even subtle language choices matter.
“Ensure” grants authority.
“Surface and flag” preserves it.
If you want bounded behavior, you must declare it.
A clearer version might look like this:
This agent is responsible for detecting structural inconsistencies introduced during toolkit iteration, so that cross-toolkit coherence is preserved, without proposing redesign beyond the defined scope.
One job.
One boundary.
Define What Success Means
Before you map failure, define success.
If the agent is doing its job well:
It surfaces inconsistencies.
It does not redesign.
It labels unsupported conclusions.
If it starts optimizing structure or inventing new framework elements, it has crossed its boundary.
That clarity becomes your Responsibility Success Profile.
It defines:
What “good” looks like
What must never occur
What counts as failure
When success is explicit, drift becomes visible.
Make Authority Transitions Visible
In traditional projects, you maintain decision logs and escalation paths because authority shifts over time.
Ownership shifts.
Context evolves.
Assumptions break.
The Responsibility Failure Map serves the same function for an agent and is the next step in the process. I’ll walk through this artifact in a future post.
It helps you see where authority could quietly expand — before it happens.
And that visibility is the difference between refinement and redesign.
A charter introduces the idea of responsibility.
But systems need something more precise than a metaphor.
They need a clear boundary between capability, authority, and responsibility.
→ Next: What Is an Agent’s Job?
The structural model behind Responsibility Engineering.
This article is part of the Responsibility Engineering series at the Empathetic Agentic AI Lab.
The drift pattern is exactly what happens in retail agent deployments. You scope it for product recommendations. Three months later it's answering return policy questions because the boundary was never declared - just assumed.
Nobody catches it until a customer acts on wrong information. Scoping the job upfront sounds obvious. In practice it gets skipped because everyone is focused on the demo, not the boundary conditions.
This a good reminder to be precise in your language when building agents. Thanks so much! Looking forward to reading more of your work.