Shipping your first agent to production

A team’s first agent matters more than the ones that follow: if it helps, others will follow; if it disappoints, it will take months to win back trust. Here is the approach we recommend, step by step, to go from an idea to an agent running in production, under control.

Pick a narrow first use case

The right first use case is not the most ambitious one; it is the one where the agent can succeed quickly and where its mistakes are easy to catch. It ticks most of these boxes:

• A repetitive task, done often, by several people.
• A process already written down somewhere: a procedure, a template, examples.
• A result you can check at a glance.
• A mistake that can be caught before it has consequences.
• A willing team, ready to review the first results.

Sorting incoming tickets, drafting standard replies, summarising meeting notes or entering invoices are good candidates. A decision that commits the company, such as a price or a hire, is not.

Describe the agent

Describe the agent as you would to a new colleague: its goal, what triggers it, the actions it can take and the expected result. In Scalt, the Agent Builder starts from this description to propose a first version: it assembles the skills needed, detects the tools to connect and plans the tasks. A good description fits in a few sentences; if it takes ten, the use case is probably too broad.

“When a ticket arrives in the support queue, read it, find the customer and their previous tickets, classify the request using our grid, draft a reply from the knowledge base, and leave it as a draft for approval.”

Choose the sources and tools

Connect the minimum: one or two sources, the ones where the useful information really lives. Each source keeps its access rights, and the agent only reads what its user can read. For tools, start with reading; only open writing, such as sending a message or editing a record, one action at a time, once approvals are defined.

Dry-run it

Before any deployment, chat with the agent and have it call its tools in a sandbox. Then take a few real cases the team has already handled, run them by hand, and compare: what the agent would have done, what the team did. The gaps tell you what to fix in the instructions or sources. Repeat until the remaining gaps are acceptable.

Define approvals and limits

Write down in black and white what the agent is allowed to do. In Scalt, each agent is packaged as an application with its approval rules, turnaround targets, a daily spending cap and an activity window. Above that, a governance profile sets the allowed models, permitted tools, mandatory approvals and caps shared by several agents.

Publish, version, roll back

An agent is published like software: a version, a trigger, rules. It can be called from the chat, a Slack command, a scheduled job, a webhook or an API. Every execution keeps the agent version that produced it; if a new version disappoints, you go back to the previous one.

Supervise the early days

In the first weeks, review the agent’s cases, not only the failed ones. The Inbox gathers what is waiting for approval and what failed; each case shows the steps, the sources read and the decisions. Widen the scope when the team approves without correcting, not before.

Measure honestly

Measure what the agent actually does: tasks carried through, the share of results approved without changes, errors stopped at approval, cost per execution. Be wary of flattering indicators, such as the number of conversations or agents created: they say the tool is used, not that it is useful.

And after the first agent?

What the first agent taught you can be reused. Instructions that work become a skill, with its tools and output format, installable on other agents. Proven applications, skills and tools are published in your organisation’s Factory, where other teams install them instead of starting from scratch. The second agent is then built faster, on foundations already checked.

The checklist

1. A narrow use case, chosen with the team that will use it.
2. A description of a few sentences: goal, trigger, actions, result.
3. One or two sources, with their access rights checked.
4. Read-only tools first; writing opened one action at a time.
5. A dry run on real, already handled cases, with gaps fixed.
6. Mandatory approvals written down for every action that commits you.
7. A spending cap and an activity window.
8. A published version, and the ability to go back to the previous one.
9. Someone who reviews the cases during the first weeks.
10. Usefulness indicators, not just usage ones.