From prototype to production: running an agent for a team

The agent is the same program. The duties around it are what grow, and there are five.

None of that is exotic. It is the same list a server or a scheduled job has needed for years, and the agent inherits it the moment somebody else's work depends on the answer.

An agent acting as you is a problem with a delay on it. Your access ends when your job does, and everything it did is filed under your name. So the first change is a separate identity for the agent.

Microsoft's Entra Agent ID does this by making an agent identity from a blueprint. The identity has no credentials of its own and signs in with federated credentials issued by the blueprint, and administrators can see every agent, its owner and its risk in the admin centre. AWS does the same shape from the other side: Bedrock AgentCore gives each agent a distinct identity that can federate with Okta, Entra ID or Cognito.

The trade-off is honest and worth naming: an agent identity is another thing to administer, and a permission scoped too widely is now a permission scoped too widely for the whole company.

A key in a file on a laptop is a key in a backup, in a screenshot and in a support ticket. In a managed store it is fetched at run time and rotated on a schedule, which is exactly what AWS describes Secrets Manager as being for: replace hard-coded credentials with a runtime call, and configure automatic rotation.

Where a key must reach a build or a job, it goes in the platform's encrypted secrets and is referenced by name, never written in the file. GitHub's own instructions are to store the value as a repository secret and read it as a variable, so the repository holds the name and not the key.

One habit makes the rest work: a key that has ever been committed is rotated, not deleted. Removing the line does not remove it from history.

A useful run record is a tree, not a diary. For each run: which agent and which version, which model, the input, every tool call with its arguments and its result, the output, the cost, the time it took, and how it ended.

The vocabulary for this is settling. OpenTelemetry's GenAI conventions name the operations and attributes — an agent invocation, a tool execution, token counts, a conversation id — and its own status page says the work is still in development, so treat the names as a direction rather than a fixed standard. Observability tools such as Langfuse, LangSmith, Arize Phoenix, Braintrust, Helicone and Sentry all speak that shape or wrap it.

If you sell into the EU, records stop being a preference. The AI Act's Article 12 requires high-risk systems to be able to log events automatically over their lifetime, and Article 26(6) expects deployers to keep those logs for at least six months. Most obligations are dated from 2 August 2026 on the trackers that follow the Act. Check the current text before you rely on any of those dates: the Commission's own service desk notes that Article 12 has been amended, and its published wording had not caught up.

Rule lists read best as three answers, and that is how the tools built for this do it. Claude Code takes rules as allow, ask or deny and evaluates them deny first, so a broad refusal beats a narrow permission. The OpenAI Agents SDK describes the same idea as guardrails that raise a tripwire when a run crosses a line.

What belongs in the ask list: money leaving, anything published under the company's name, anything deleted, and anything sent to a person outside the building. Give those a named approver rather than a shared mailbox nobody admits to owning.

Runaway consumption is its own documented risk class: OWASP lists unbounded consumption, and the controls are unglamorous. A token budget per run, a cap on iterations, a timeout, and a rule that stops a loop repeating the same action.

Model providers carry account-level spend limits too — OpenAI's are documented — and it is worth setting one on day one rather than explaining an invoice on day thirty.

Four jobs, and the names that come up for each. None of them is required, and an agent template carries between them: the instructions, the skills and the configuration are the portable part.

That last row is the one teams skip and then regret. Prompts change behaviour quietly, so a review by eye is not enough; a small suite that has to stay passing is what tells you a model upgrade did not move the answer.

The teams that get this wrong usually do it in one step: straight from one person's laptop to the whole department press. Four smaller steps survive better.

• One person, one job, one folder. Nothing to approve.
• A pack someone else can run: a README, the skills, a version note, and a licence.
• One team, with a named owner, a key in the manager, and a record you can read.
• Wider, once the records exist and the risky steps have approvers.

The test before the last step is simple: could you answer, from the records alone, what it did last Tuesday and why? If not, the answer is more records, not more users.