Agent Teams and Long-Horizon AI: How an Office Runs Multi-Step Work

The most useful part of the Opus 4.6 release is not a benchmark score. It is that the model was tuned to stay inside a long job for hours and to run beside a team of other agents at the same time. For a service business that is the whole story, because the work that eats your week is rarely one clever answer. It is the month-end close, the batch of reports, the stack of documents that has to be handled the same way every cycle. I am Madhuranjan Kumar, and this is the playbook I use to hand that kind of long, repeating work to a team of agents without losing control of it.

Find the jobs that repeat before you touch a tool

The first move has nothing to do with the model. It is to walk your own operation and list the jobs that come back every week or every month and follow the same shape each time. A weekly report built from the same three sources. A reconciliation that runs the same checks. An onboarding sequence that sends the same documents in the same order. These are the candidates, because a long-horizon agent earns its keep on repetition, not on rare judgment calls.

The test is simple. If you can explain the job to a new hire as a written checklist, an agent can run it. If the job depends on a gut read that changes every time, leave it with a person for now. Sort your recurring work into those two buckets and the automation targets pick themselves. Most owners are surprised by how much of the week sits in the first bucket, the rule-bound grind that never quite gets done on time.

A useful trick during this audit is to time the jobs, not just name them. Write down roughly how many minutes each one costs and how often it runs, because that number tells you which automation to build first. A ten minute task that runs once a month is not worth the setup. A thirty minute task that runs twenty times a month is where the payoff lives. Rank your list by total monthly minutes and start at the top. The point of a long-horizon model is to eat the jobs that are individually boring but collectively enormous.

Write the job down as rules, not as a wish

Once you have a candidate, write it down as an explicit set of steps and the rules each step must obey. This is the part people skip, and it is the part that decides whether the whole thing works. The larger context window in this release means an agent can hold a genuinely big instruction set in mind at once, so you are not forced to keep it vague. Spell out the inputs, the order, the checks, and the definition of done. If a balance must tie to the penny, say so. If a report always groups by region before product, write that. The document you produce is not paperwork, it is the agent's operating manual, and a sloppy manual produces sloppy output no matter how strong the model is.

A good habit here is to write the rules the way you would brief a careful new employee. Include the exceptions you know about, because the ones you leave out are the ones that will bite you. Describe what a good result looks like and what a bad one looks like, so the agent has a target rather than just instructions. If there are three ways a step can fail, name all three and say what to do about each. The half hour you spend writing the exceptions down is the half hour that saves you from silent errors later.

This same written foundation pays off elsewhere too. The clearer your processes are on paper, the easier it becomes to feed them into your CRM and website stack so follow-up and record-keeping run off the same source of truth the agents use. A business that has never documented its own workflow tends to discover, in this step, that half its problems were never about tools at all. They were about a process that lived only in one person's head.

Prove the workflow with one agent first

Do not start with a team. Start with a single agent running the whole job end to end while you watch. This release ships stronger self-correction, meaning the model is built to catch its own mistakes mid-task and repair them instead of confidently handing you a flawed result. You want to see that behavior on your real work before you trust it. Run the job once, read every step of the output, and note where it drifted from your rules. Tighten the written instructions where it went wrong. Run it again. When a single agent can complete the job cleanly two or three times in a row, you have a workflow worth scaling, and not before.

This slow start feels like it wastes time. It does the opposite. A team of agents built on a shaky workflow just multiplies the errors, so the patient single-agent proving stage is what makes the fast part safe later. Treat those first few runs as training, both for the agent and for you, because you will learn as much about your own process as the model learns about the rules. Almost every owner who does this finds a step in their workflow that was never actually necessary, or a check that everyone assumed someone else was doing.

Split the proven job across a team

Now you scale. Instead of one agent grinding through the job step after step, you run several in parallel under an orchestration layer that keeps them coordinated. The pieces that do not depend on each other happen at the same time. One agent pulls and categorizes data while another runs the reconciliation and a third drafts the narrative, all at once. A task that used to mean thirty minutes of stop-and-start can finish in a few minutes, because the slow back-and-forth is gone.

The orchestration matters as much as the speed. Left uncoordinated, parallel agents clash and duplicate work, two of them editing the same thing or each assuming the other handled a step. The orchestration layer is what turns many workers into one team, handing each its slice and assembling the results. Think of it as the manager you never had to hire. The skill on your side is deciding which parts of the job are truly independent and can run at the same time, and which parts have to wait for an earlier step to finish. Get that split right and the parallel speedup is real. Get it wrong and you get a fast mess.

Let each agent check its own work, then pick the cleanest result

Two review habits make the team trustworthy. First, lean on the self-correction. Ask each agent to verify its own numbers and outputs against the rules before presenting anything, so errors get caught inside the run rather than in your lap. This is the single biggest change from earlier models, which would hand you something wrong with full confidence. Now you can instruct the agent to prove its own result before it shows you, and a caught error is worth far more than a fast one.

Second, when agents run in parallel you often get more than one version of a result. Do not blindly accept the first. Review what each produced and keep the version that is correct with the least clutter, the same rule of thumb a good manager uses when two people solve the same problem two ways. Over time you will notice which parts of the job the agents nail every time and which parts still need your eye, and you can tighten the review to focus only on the parts that actually vary.

Keep the human gates where money and compliance live

Long-horizon autonomy is powerful, and that is exactly why you keep a person at the gates that carry real risk. Anything that gets filed, paid, or sent to a client stays behind a human signoff. The agents do the keying, the pulling, the drafting, and the checking. A person does the approving. This is not a lack of trust in the tool, it is how you get the speed of automation without betting the business on an unattended machine. Set those gates deliberately, mark them in your written rules, and never let the workflow route around them.

The mistake I see most often is the opposite of caution. Owners get one clean run, feel the speed, and remove the human check to go faster. That is exactly when a silent error slips into a filing or a payment. The gate is not a bottleneck to optimize away. It is the insurance that lets you run everything else fast. Keep the person on the decisions that would hurt if they were wrong, and let the machine own everything before that point.

A month-end close, run as a playbook

Here is the shape of it for an accounting practice closing the books for a batch of small-business clients. Before any tool, the close gets written as an explicit checklist per client: pull transactions, categorize, reconcile the bank feed, flag variances, draft notes. That checklist becomes the instruction set. A single agent proves it on one client file first, and the team scales it once it holds.

On close night, an agent pulls and categorizes transactions for a client while a second reconciles the bank feed and a third drafts the variance notes, several clients moving at once instead of one after another. The large memory lets each agent hold a full ledger without losing the thread. When a balance does not tie, the agent flags and reworks it rather than passing along a silent error. A staff accountant reviews the output and keeps the clean version, and a partner still signs anything that touches a filing or a payment.

Put illustrative numbers on it. Say a close that used to take one person thirty minutes per client, done sequentially, now runs several clients in parallel and lands the first pass in about five minutes each after a month of tuning. Across a book of forty clients, that is the difference between the close swallowing a full week and the close finishing in a day or two, with the team spending its hours reviewing instead of keying. If a single staff accountant used to lose three full days a month to the mechanical part of the close, and that shrinks to half a day of review, the practice just recovered more than two working days a month per person on the close. Those figures are illustrative, not a guarantee, but the direction is the point: the long, repeating job compresses hard while the humans move up to judgment.

Where this connects to the rest of the business

The same discipline that runs a close well also feeds the front of the house. When your reporting and record-keeping are clean and automated, the numbers that tell you which Facebook and Instagram ad campaigns actually produce paying clients become trustworthy, and the spend on Google Ads can be judged against real close-rate data instead of guesses. The back office and the growth engine are not separate problems. A tidy operation makes every downstream decision sharper, because you are finally deciding on real numbers rather than on the rough guesses a busy team makes when nobody has time to check.

Start small and let it compound

You do not need to automate your whole company this quarter. Pick one recurring, rule-bound job. Time it, write it down properly, prove it with a single self-checking agent, scale it to a coordinated team once you trust it, and keep humans at the gates that matter. Then do the next job. Built this way, the long jobs stop owning your calendar, and the model does the grinding while your people do the deciding. The compounding is the real reward. Each job you automate frees the time to automate the next, and within a couple of quarters the shape of the week changes for good.

You can set this up yourself, one process at a time, and I would encourage any owner to start with the single job that hurts most. If you would rather have the workflows, the written rules, and the review gates built for you so the long jobs simply run, that is the kind of system I set up for clients, and you can bring me in to handle it.