This post used to be built around the number of agents I had deployed. That count came from an earlier experimental setup that has since been retired, and counting agents was the wrong scoreboard anyway. Rewritten around what survived contact with production.
Building an agent is a weekend. Running agents that operations staff rely on is a different discipline entirely. After a year of doing the second thing across an industrial operations group, the list of what works is shorter and duller than I expected.
What works
A registry, not a collection. Every agent is declared in one place with a named owner, an autonomy tier and a cost ceiling. If nobody owns it, it does not run. This one rule killed more bad ideas than any review meeting.
Autonomy in tiers. Most agents read and suggest. A few act inside a narrow boundary. Almost none act on production data without a person approving the write. Deciding the tier before building settles most design arguments.
Evaluations before production, on your own data. Vendor benchmarks are marketing. What matters is accuracy on your documents, your language mix, your edge cases. Set the threshold before the test so you cannot move it afterwards.
Narrow tools over general access. An agent with twelve specific, tested tools beats one with a database connection. Narrow tools are reviewable, and they fail in ways you can predict.
Embedding in existing workflows. The agents people use are the ones that put the answer where they already look. The ones that required a new interface are the ones sitting idle.
Failing loudly. An agent that silently returns a partial answer is worse than one that stops. Operations people will forgive an error message. They will not forgive a number that was quietly wrong.
Not how many agents you have. How many are in daily use by someone outside the technology team, and whether they would complain if it stopped.
What does not work
Sprawl. A large number of agents is a symptom, not an achievement. Most of them overlap, most were built for a demo, and each one is surface area you now have to secure and maintain.
Chat as the only interface. A dispatcher on a warehouse floor is not going to craft a prompt. For operations, the right surface is usually a button, a scheduled digest, or a field that fills itself.
Memory without permission scoping. Agents that remember across users will eventually tell someone something they should not have. Scope memory the same way you scope data.
"An agent for everything". Some problems are a database index, a corrected master data record, or a conversation with a department head. Reaching for an agent first is how technology functions lose credibility.
The operations reality
Three things are true in an industrial setting that rarely feature in AI writing.
Users are bilingual, and often more comfortable in Hindi than English. Connectivity at a site is not the connectivity in your office. And the people whose work you are changing did not ask for it.
That last one decides more outcomes than the model does. The agents that stuck were the ones where someone in the business had agreed, in advance, that the problem was worth solving and that they would use the result. The technically better ones without that agreement are in the archive.
Where I would start again
- One agent, one owner, one measurable process.
- Read-only until it has earned the right to write.
- Evaluations and thresholds written down before the build.
- The interface where the work already happens.
- A date by which it is either adopted or switched off.
Nobody outside technology has ever asked me how many agents we run. They ask whether the number on their screen is right, and whether it will be right tomorrow.