Work · Specialized Agents
Start with a real job. Then build the context, tools, state and boundaries the system needs to take part in that work.
Most agent projects begin with a model and a framework and then look for work to give them. That order is why so many of them stall in a demo: the hard part was never the model.
We start with the job. What triggers it, what information it needs, which decisions it contains, what it produces, which systems it touches, and what happens on the cases that do not fit the normal path.
Exceptions and escalation deserve particular attention, because they are usually where the value and the risk both sit. A job with no defined exception handling is not yet a job an agent can do.
Specialization does not come from a prompt describing a role. It comes from what the agent is actually connected to: domain context, the tools it can operate, the state of the process it is in, memory of what came before, the rules it works under, the permissions it holds, and a way to evaluate whether it did the job.
A general assistant with a job title in its system prompt is still a general assistant. A specialized agent knows which case it is in.
The model is one component among several. What surrounds it decides whether the agent is useful.
Writing down what an agent may not do is harder, and more useful, than describing what it can. It forces the decisions nobody made explicitly: which actions are reversible, which need a person, what happens when confidence is low, and who is accountable for the outcome.
We do not optimise for maximum autonomy. An agent that hands off well at the right moment is worth more than one that proceeds confidently through a case it has misread.
Permissions belong here too. An agent inherits the access it is given, and the right question is not what it could reach but what this job justifies.
A narrow job is an efficiency decision before it is anything else. It means the agent needs task-fit context rather than the company's knowledge base, can reuse state instead of rebuilding it each run, and does not loop through calls that add no information.
Where selection, reuse and measurement of context are part of that, LeanCTX can provide the layer. Better context can sometimes make a smaller model sufficient — sometimes, and worth testing rather than assuming.
None of this is a cost argument first. A cheaper agent that does the job badly is not efficient.
An agent is evaluated on the job, not on a conversation. That means running it against cases whose outcome is already known.
Quality: did it complete the case, was it correct, how much rework did a person do afterwards, how often did it escalate and was that escalation right. Resources: how many calls and tokens it took, how long it ran, what it cost.
Completion · Correctness · Rework · Escalation · Tokens · Cost
Both halves have to be read together. Either one alone can be improved by making the other worse.
Tell us what happens today and what you want the agent to take on.