AI agent orchestration: work beyond the chat

You ask an agent to review last month's books. It checks the records, finds a gap and asks a question. You answer the next morning. Does the work continue, or do you have to explain the task again?

AI agent orchestration earns its place at that handoff. It connects the trigger, the work period, saved progress, human input and the result. A useful agent can take responsibility for a bounded task while you are doing something else. The test is whether you can leave, return and understand what happened.

My position is simple: recurring work deserves a lifecycle that the user can see.

What is AI agent orchestration?

Orchestration decides when an agent starts, which step it can perform, what makes it stop and what allows it to continue. The model still reasons about the task. The surrounding system owns the sequence and the recorded status.

Consider a monthly review. “Run on the third” is incomplete. The task also needs a period to inspect, a way to remember completed checks, a place to ask for missing information and a definition of finished. Those details determine whether delegation survives an interruption.

These are design patterns, rather than universal product limitations.

Our earlier explanation of AI accounting agents covers the domain choices. Orchestration carries them through time.

Why are AI agents moving beyond chat?

Two September announcements show where the industry is investing. On September 10, 2026, Atlassian described agent loops in Jira that scan suitable work items, delegate execution and open pull requests for review. The loops were in private early access, rather than general availability. The human still controls what ships. Atlassian's announcement

On September 24, LangChain launched LangSmith Trajectories, a chronological view of the messages and actions in an agent session. It gives reviewers a readable path through work that can span multiple turns and tool calls. LangChain's announcement

I read these as two sides of the same problem: let work continue, then make its history understandable. Neither announcement proves an accounting workflow is reliable. They do make the conversation more concrete than a contest over which agent gives the most impressive first answer.

How do scheduled AI workflows choose the right period?

On September 29, we released an orchestration update at Norman covering scheduling, answers to waiting workflows, recovery of interrupted thinking steps and summaries of completed work.

Take a month-end close scheduled for October 3. Its review period should be September 1 through September 30. Running a careful review of the first few days of October would answer the wrong question. Our scheduled close and reconciliation workflows therefore bind the run to the previous calendar month.

That example illustrates the behavior; it is not a customer result. A deadline-based preparation workflow follows the relevant report's period instead. A quarterly period must not become a monthly one merely because the scheduler wakes up in October. Preparation also does not confer permission to submit a filing.

The user explicitly enables the schedule. The card shows its next run and offers controls to change or stop it. Scheduling is subject to the product's plan access. An older run waiting for a person must not be mistaken for successful dispatch of a new period. We keep that distinction in the orchestration, rather than asking the model to infer it from the conversation.

What should happen when an AI agent needs an answer?

Our September 30 production snapshot contained dozens of active workflows waiting for a person. Most of those runs had been created more than a week earlier. That is an operational snapshot of stored runs, not a measure of how long every question had been waiting or of the release's impact.

It exposes a practical weakness: keeping a task alive is insufficient if answering it does not reliably move the task forward.

The update makes the answer part of the waiting step. A reply on the workflow card records it, clears that question's block and lets the runner continue. An answer in the run's own chat can take the same path after the chat turn ends. If that turn asks a new question, the new question remains open. “A message arrived” is not a sufficient reason to assume every dependency has been resolved.

We also close designated review steps when no transactions, invoices or bills for the period have reached Norman. A handful of steps already carried that outcome in the snapshot. It means there was nothing available to review, not that the business had no activity. Missing bank data can still need attention. The broader distinction between waiting and failure is covered in long-running AI agents.

How should an interrupted AI workflow recover?

A thinking step can lose its worker without having finished. The recovery path checks whether execution is still alive before making that step eligible to run again. A genuine human question stays paused. A recorded failed action requires an explicit retry.

That separation is especially important when tools change something outside the agent. If an external request might have succeeded before its response disappeared, repeating the request can create a second effect. Saved progress does not prove that repeating it is safe.

We guard recorded action starts against automatic repetition and distinguish them from interrupted thinking. I would not describe this as a general guarantee that every external action happens exactly once. Such a guarantee depends on the receiving system and on how the particular action is reconciled. Our article on AI agent retries explains that boundary in more detail.

The status should point to the next decision: answer, inspect, retry or let execution continue.

How do you know what the agent completed?

A scheduled start is an attempt. A finished workflow is an outcome. A finished scheduled run can produce a note with its period, step outcomes and items to inspect. The weekly overview counts completed workflows alongside recorded categorization, rule applications and reminders. The weekly email also lists work awaiting attention.

These counters help answer “what happened while I was away?” They do not demonstrate accounting accuracy or time saved. The summary's time estimate uses fixed assumptions about activities; it is not a stopwatch measurement. A workflow completed with warnings still needs its warnings read.

At the September 30 snapshot, we had no completed workflow marked as schedule-triggered. The feature had just shipped. It would be premature to turn the release into a throughput benchmark or a claim that human waits have disappeared.

A useful summary makes incomplete work visible alongside completed work. The user can switch weekly summary emails off.

What should you test before delegating recurring work?

Start with a task whose period and finish line you can state. Then test the whole lifecycle: enable a schedule, inspect its period, interrupt execution, answer a question later and read the final result. Include an empty period and an uncertain external action. A demonstration that only follows the uninterrupted path tells you little about delegation.

Measure separate outcomes. Did the right period start? Did an answer release the right step? Did recovery preserve a real human block? Did the result disclose warnings? Counting agent turns cannot answer those questions.

Next we need a comparable observation window for completion and human intervention. Yesterday's release lets us observe that.

I want users to remember the decision they still need to make, rather than reconstruct the conversation that produced it. That is the responsibility our orchestration now has to earn.