Stop Building Agents That Do One Thing
An agent that answers questions about open purchase orders, and nothing else, needs a prompt, a connection to the purchasing system, a test plan and an owner. Build the next one for support case summaries and you’ve doubled all of that. Build ten and you have a small software portfolio nobody budgeted for. Plus a catalog of tiles where the person with the actual question has to know which one to click.
The better general agents don’t live inside a single application anymore. They read the same mail, calendars, files and chat history you do, and connectors carry them into the ERP and the CRM. What matters is whose eyes they use. A well-built connector runs under the identity of the person asking, so the agent sees what that person’s role allows and nothing more. That’s the same security model your ERP already enforces.
My argument is not complicated. If one general agent can already reach all of that under your own permissions, the thing to build for each repeatable job is a skill for that agent. Not another agent.
Why point agents break
Real questions don’t stay inside one system. Take a supply chain manager asking why a customer’s order will ship late (an illustrative example, not a client story). The purchase order and its confirmed delivery date live in the ERP. The vendor’s explanation is sitting in a buyer’s inbox. The customer’s complaint might be a service case, or it might be a chat thread with the account manager. A purchase order agent sees one piece and answers with total confidence about that piece.
Then there’s routing. With ten point agents the user carries a mental map of which agent knows what. I’d bet the first confident wrong answer from one of them costs trust in all ten. A general agent puts the routing decision back on the system, which is the one doing the reasoning anyway.
Every point agent is also a small software product. Somebody owns its prompt and its connection. Somebody else gets to retest it after every vendor update that touches the tables it reads, and that work never shows up in the original business case.
Permissions are the part I’d lose sleep over. A point agent built on a shared connection or a service account runs as whoever wired it up, for everyone who uses it. One permission model to audit beats one per agent.
Write the skill instead
A skill is the piece that makes point agents hard to justify. In the agent tools that support them, a skill is usually just a folder with a Markdown file in it. The file opens with a name and a short description of when to use it, and the rest is plain instructions, with room for a reference document or a script alongside. There’s no app to register and no connection to configure.
Take a month-end cost summary for one legal entity. A point agent for that job needs its own connection to the ERP. A skill needs none, since the general agent already has one. What’s specific to the job is the procedure: which entity to pull and what the workbook should look like when it lands.
The agent reads the descriptions of the skills it has and loads one when the conversation calls for it, so nobody has to remember which tile to click. The description does the routing. Write it too broad and the skill fires when it shouldn’t; leave out the phrases people actually use and it never fires at all. I’d rather debug one sentence of description than a tenth agent.
A skill holds instructions, not credentials, and it runs in the session of whoever invokes it, so the connectors still check that person’s roles. Treat one from outside the company the way you’d treat a spreadsheet macro from outside the company.
Where a dedicated agent still earns its keep
I’m not arguing for zero dedicated agents. A general agent is built around a person describing an outcome and approving actions as it goes. Work that has to run unattended against every inbound vendor invoice, at whatever hour the invoice arrives, is a different shape of problem, and a narrow agent triggered by that event is the better fit.
Cost is the other honest objection. Many general agents bill by usage, so spend moves with how people use them. A narrow agent with a fixed workload is usually easier to put in a budget line.
And then there’s write access. A general agent with ERP connectors can usually change records as well as read them, under the invoking user’s permissions. Hand it to a power user whose roles already let them post journals and approve payments, and the agent can do anything those roles allow, subject to whatever approval step the tool puts in front of it. A point agent with a tight scope is a fence somebody built on purpose.
So my default is one general agent and a folder of skills, with point agents only where something has to run without a human in the loop. Before the ERP connector goes out to the whole finance team, though, somebody should pull the security role assignments for those users and read them line by line. Start with anyone who still has full administrator rights.
If you’ve built a single-purpose agent that a skill couldn’t have replaced, tell me what it does in the comments. I’d especially like to hear from anyone running one against an ERP.
Gamifying the Enterprise (my book): www.amazon.com/dp/B0GY3VWLVX
All my books: www.amazon.com/author/murrayfife
