Product
What we mean by an agent management system?
Building an agent is the easy half. The hard half is everything that decides whether you can leave it running: identity, approvals, triggers, and a record of what it did.
Most teams get their first agent working in an afternoon. A prompt, a model, a couple of tools, and something that answers questions about your data. The demo is genuinely impressive, and then it sits there, because nobody can answer the next question: who is it acting as, what is it allowed to change, and how would we know if it got something wrong?
An agent management system is the answer to that second question. It is the layer between a working prototype and something a business is willing to leave switched on.
Four things a prototype never has
- An identity. Every tool call happens as someone - the agent's own service connection, the person who started the session, or a credential supplied on the entry call. Which one it is decides what the agent can reach and whose name is on the audit row.
- A place for people to stay in control. Some actions should stop and wait for a human. That decision belongs in the agent's configuration, not in the wording of a prompt.
- A way to start that is not a chat box. Real work arrives on a schedule, from your API, or from an event in a system you already run.
- A record. Every model turn and every tool call, kept long enough to answer a question somebody asks next quarter.
Identity is the one people underestimate
It is tempting to give an agent one powerful set of credentials and move on. It works immediately, and it quietly makes every later question unanswerable: the audit log in the connected system shows one service account doing everything, so "who deleted that record" has no answer beyond "the agent did".
Binding a tool to an identity is a configuration decision in Yekar, made per agent and per integration. An agent can act as the domain's shared connection, as the person who triggered it, or with a credential handed to it on the way in and thrown away when the run ends. There is no fallback between those modes - an agent configured to act as its caller does not quietly borrow the organisation's stored credential when no caller token arrives.
Approvals are a control, not a prompt
"Ask me before sending anything" in a system prompt is a request. The model usually honours it. Usually is not a control, and the gap between usually and always is exactly the class of incident that gets agents banned from a company.
A safeguard that lives in the prompt is a safeguard the model can talk itself out of.
So gated actions pause the run and wait for a named approver. The agent's turn suspends, the person decides, and the run resumes from where it stopped - with the decision recorded beside the call it authorised.
The record is the product
Once an agent is doing work that matters, the transcript stops being a debugging convenience and becomes the thing you are actually buying. What did it read, what did it change, which model produced that answer, which version of the configuration was live at the time, and who approved the one step that needed a person.
That is the whole argument for a management system. The agent is the easy part. What lets you leave it running is everything around it.