Multi-agent workflow orchestration in Bellevue
After Hours IT provides multi-agent workflow orchestration for businesses in Bellevue, WA and the surrounding area. Downtown Bellevue and the Spring District mix corporate offices with growing storefronts; we’re on the Eastside nightly.
We schedule ai automation & agents engagements around your team's availability, with on-site visits to Bellevue when the work requires physical access.
Multi-agent workflow orchestration: when one AI can’t safely do the whole job
On a rainy Thursday evening, a regional equipment distributor called us because their new AI assistant was doing the first half of the work fine, then making a mess of the second half. Their research agent could gather vendor pricing, compare lead times, and draft a recommended order. But the action agent was allowed to send the purchase request automatically, and that is where things went sideways. A few wrong SKUs and one duplicate submission later, the office manager wanted the automation to stop before it created another weekend cleanup.
We hear this pattern a lot with multi-agent setups: one agent is good at collecting context, another is good at taking action, but the handoff between them needs guardrails. In this case, the business had scheduled runs every morning at 6:00 AM to prepare replenishment orders before staff arrived. The workflow was supposed to save time, but without an approval step between research and execution, it was moving too fast for a business that still needed a human to confirm quantities, exceptions, and vendor selection.
What we found in the workflow
We started by reviewing the orchestration layer, not just the individual agents. Their scheduler was triggering a Python job from a Windows Task Scheduler entry, which then called a workflow service built around two agents: a research agent that queried vendor APIs and scraped portal data, and an action agent that created draft purchase orders in their ERP. The logs showed the research agent returning clean JSON, but the action agent had no hard stop if the approval flag was missing or stale. It would fall back to the last valid output in memory, which explained the duplicate order.
We checked the agent prompts, the tool permissions, and the state handoff between steps. The research agent was using HTTPS calls with API keys stored in environment variables, while the action agent had access to the ERP through a service account with broader permissions than it needed. We also found that the approval record was being saved in a local SQLite file on the app server, which made it fragile during restarts. If the scheduled job overlapped with a previous run, the workflow could pick up the wrong approval state and move ahead anyway.
How we rebuilt the approval step
Our engineers reworked the flow so the research agent now ends with a structured summary: vendor, item, quantity, price, exception notes, and confidence score. That summary is written to a shared queue and then posted to a review screen where the office manager can approve, reject, or send it back for revision. Only after approval does the action agent receive a signed job token with a short expiration window. We used JSON schema validation at both steps so the action agent could not run if any required field was missing or if the approval token had expired.
We also tightened the scheduling and retry behavior. The job now runs in a controlled 6:00 AM window with a lock file and a database-backed run history to prevent overlap. For the action side, we limited the ERP service account to create drafts only, not final submissions, and we added a second confirmation call for any order above a set dollar threshold. Everything was documented in their runbook, including the agent prompts, API endpoints, approval logic, and rollback steps if a vendor API times out or returns partial data.
The follow-up and what the office team saw
By the next scheduled run, the workflow was behaving the way the business actually needed it to behave. The research agent still did the heavy lifting, but now the office manager got a clean approval packet each morning with side-by-side vendor comparisons and a clear note on anything unusual, like backorders or price changes. The action agent only acted on approved items, and the ERP showed draft purchase orders instead of live submissions until a human signed off. That gave the team time to catch a couple of small exceptions before they turned into costly orders.
After go-live, we monitored the logs for a full week and reviewed the execution traces with the client. We confirmed that the approval handoff was preserved in the audit trail, including timestamps, user ID, and workflow version. We also left them with a simple checklist for future changes: update the schema when adding a new field, test the scheduler after any server patch, and never give the action agent more permissions than the task requires. That kept the automation useful without letting it run loose.