Which business process should get your first agent?

Most firms ask which process is the most repetitive, or which one eats the most hours. That is the wrong question to start with. A repetitive process with unclear rules breaks an agent faster than a rare process with clear rules.

There is a second problem. In most services firms, AI is already in the process. One person runs it through Claude, another through ChatGPT, a third still does it by hand. The same job gets done five different ways, and nobody can say afterwards which tool made it or who checked it. So the first agent is not really about adding AI. It is about deciding, for one process, how the whole firm does it.

That changes two things: which process you choose, and where you build it. A firm that treats its first agent as automation gets a task off someone's plate. A firm that treats it as a capability gets something it can reuse: one agreed method, a named person at the gate, and a record of who approved what. The first firm has one less chore. The second has learned how to hand a process over and keep control of it. That difference compounds with every process that follows, but only if every process is built in the same place.

Three tests, in order

Run every candidate process through these three tests before you pick one.

1. Clear inputs, clear outputs. The agent needs to know exactly what it is working from and exactly what a finished result looks like. "Read the market and summarise what matters" fails this test. "Read this client request and fill in our brief template" passes.
2. A named person can check the answer in under a minute. That person is the gate. If they need ten minutes to judge whether the output is right, the agent has not saved time. It has moved the work, not removed it. The best first processes produce an answer a person can confirm at a glance: a number, a tag, a short decision.
3. A wrong answer costs little. Early agents make mistakes. The first process should be one where a mistake is cheap to catch and cheap to fix. Nobody should hear about an error from a client first.

A process that fails even one test is not a good starting point, no matter how much time it currently costs.

What a capability looks like: client request intake

Take something almost nobody would call strategic: a new request from a client.

Today it lands in someone's inbox. One project lead writes it up as a proper brief. Another forwards it with a line on top. A third pastes it into a chat tool and asks for a summary. Whether the work starts well depends on who picked it up.

The narrow version only automates the summary. Someone builds a small script that reads the email and writes a few lines. That saves a few minutes. It is automation, not a capability.

Build it on Runbaze instead, and the same process does more.

1. The request arrives, by email, the client portal or a message. Runbaze picks it up through the tools the firm already uses.
2. The agent works from a specification the firm wrote once: the objective, the constraints, what a finished brief looks like, and the context a good project lead carries in their head. It turns the request into a brief in that format, with client, scope, deadline, budget and the team it belongs to. If something is missing, it says what, and drafts the question back to the client.
3. The brief lands on the board at a gate. A named owner approves it or sends it back, in Runbaze or from the chat tool the firm already uses. Nothing goes to the client, and no work starts, until that person decides.
4. Every run lands on the record: what came in, what the agent produced, which model ran, and who approved it.

Nothing in that flow needs judgment a model cannot make. The input always has the same shape. The owner can check the brief in seconds. A wrong team assignment costs a reroute, not a lost client. It passes all three tests above.

What the firm gets back is not an afternoon. It gets a working pattern. Every request is now handled one way, whoever picks it up. When a client asks how their request was handled, the answer is already on the record. After a month, the firm can see which clients send incomplete requests and how long it takes to get from inbox to approved brief. And the specification goes into the shared library, so the next agent, for status updates or change requests, starts from a pattern the team already trusts.

Build it on the platform, not next to it

Most first agents get built next to the work. A script in one person's account. A prompt someone saved in a chat tool. An automation that runs until the person who built it leaves. Each one removes a task. None of them gives the firm one way of working, and none of them can answer when a client asks who checked the result.

On Runbaze, the agent is built inside the layer the whole firm works in. Four things come with it from the first run.

• The specification. Objective, constraints, definition of done and context, written once. Every run follows it, whoever starts it.
• The gate. A named person decides where the consequence sits. The agent carries the volume. The person carries the answer.
• The record. Every run logs the request, the output, the model and the approval, ready for a client or an auditor who asks.
• Your own model and your own tools. The agent runs on the LLM you choose and connects to the systems you already use. Your data stays where it is, and the model stays yours to swap.

That is the difference between a first automation and a first capability. The second agent does not start from a blank page. It starts from the same specification format, the same gates and the same record, on the same platform, and the team can see it working next to the first one.

What looks tempting and fails

Some processes feel like the obvious place to start, and they are usually the wrong place.

• Architecture decisions. No fixed input, no single right output, and a wrong choice is expensive to unwind months later.
• Customer escalations. The stakes are too high for a first attempt, and a person already has to read the full context anyway.
• Anything judged on tone or taste. A first draft of marketing copy or a sensitive client email reads fine to an agent and wrong to a person, and the gap is hard to spot fast. That work can come later, with a named owner on everything that goes out.
• A final decision with nobody at the gate. A pre-check before someone reviews is a good first agent. A decision with nobody checking it is not, however confident the agent sounds.

If a process needs a senior person's judgment just to describe what "correct" means, it is not a first process. It might be a fifth or sixth one, once the team trusts the pattern.

Once you have picked it

The sequence stays the same after that. On Runbaze, a first agent goes live in four weeks, on your systems and your data.

1. Week 1: specify and agree the number. Write the process out, mark the gates, and agree one number with the process owner. Nothing is built until that is signed off.
2. Week 2: build and connect. The agent, the connections to your tools and the record are built. By the end of the week it runs on real data in a controlled setting.
3. Week 3: run alongside. The agent works next to the people who do the task today. Where they disagree is the most useful output of the week.
4. Week 4: hand over. Your team takes over the gates, reads the number, and picks the next process.

After that, the agent is yours, and it runs on the same platform as the next one. That is how a firm ends up working one way: one process at a time, all in one place.

The first test, clear inputs and clear outputs, usually comes down to data. An agent cannot work from records that sit in three systems, under three different names, half of them outdated. A Data Foundation Scan checks that before you commit: where your data actually stands, where it breaks, and what it takes to fix, so the gap shows up before you build, not halfway through.

A short conversation will tell you within thirty minutes whether your top candidate passes the three tests, and what it takes to run it on Runbaze.