Most agent setups are still synchronous at their core. You prompt, it runs, you wait, you review. That's just a faster intern, not an autonomous operation.
The shift that changed how I run 47 Industries was moving to a genuinely async architecture. Agents that trigger other agents. Work that queues, processes, and completes without me touching it. A business that makes progress between the hours I'm actually sitting at a computer.
This post is about how that architecture actually works, the specific patterns I use, where it breaks, and how I keep it from going sideways.
The Core Problem With Synchronous Agent Workflows
When you run agents synchronously, your output ceiling is your attention. You are the scheduler. You are the queue. Every task passes through you before it moves forward.
That works fine when you're learning how to use agents. But once you want to scale output, it becomes the bottleneck. You end up spending half your day reviewing things instead of building things.
The fix isn't just automation. It's changing the dependency structure. Instead of agents waiting for you, they wait for each other, or they wait for a trigger, or they wait for a condition to be true. You become the exception handler, not the foreman.
What Async Actually Means in This Context
Async agent architecture means your agents are event-driven, not prompt-driven. Work enters a queue from an external trigger. An orchestrator picks it up, breaks it down, and routes subtasks to specialized agents. Those agents complete their work and either pass results to the next agent or surface them for your review. You only enter the loop when something needs a decision that the system can't make.
Three things make this possible at a practical level.
First: a reliable queue. I use n8n for this. Every piece of incoming work, whether it's a client request, a new lead, a bug report, or a content brief, hits a webhook and drops into a queue. The queue is just a structured data store with status fields. Pending, in-progress, completed, needs-review.
Second: a stateless orchestrator. The orchestrator doesn't hold context between runs. It picks up a job, reads the spec, breaks it into tasks, assigns them, and writes the results back to the queue. Then it's done. The next run picks up the next job. This keeps it from accumulating state that corrupts later runs.
Third: agents that write their output somewhere persistent. Not just returning a response. Actually writing to a file, a database row, a Notion page, a GitHub branch. Something that exists independently of the agent session. This is what makes handoffs work without you in the middle.
The Trigger Layer
Every async system starts with triggers. These are the events that put work in the queue without you doing it manually.
In my setup, I have six trigger types active right now.
- Form submissions. Client intake form fills, a webhook fires, the job hits the queue with the form data attached. The orchestrator picks it up within two minutes.
- Email parsing. Specific inbound emails, filtered by sender or subject pattern, get parsed and converted to queue jobs automatically.
- GitHub events. Pull request opened, issue labeled, workflow failed. Each of these can spawn an agent job without me touching it.
- Scheduled jobs. Weekly report generation, monthly invoice drafts, recurring content briefs. These fire on a cron schedule and hit the same queue.
- Slack commands. I can drop a job into the queue from my phone by sending a message to a specific channel. Fast, no context switching required.
- Agent-to-agent triggers. When one agent completes a task, it can write a new job to the queue for a downstream agent. This is how multi-step pipelines run without me as the connector.
The key insight with triggers is that you're encoding your own judgment into the trigger rules. You're not removing yourself from the decision, you're moving your decision upstream. Instead of deciding whether to start a task, you decided once, at the trigger level, under what conditions a task should start automatically.
The Orchestrator Pattern I Actually Use
The orchestrator is a Claude-based agent that runs on a five-minute poll cycle. It checks the queue for pending jobs, picks up the oldest one, and processes it.
The system prompt for the orchestrator is deliberately minimal. Its job is task decomposition and routing, not execution. It reads the job spec, breaks it into no more than five subtasks, assigns each subtask to a named agent type, and writes that task plan back to the queue as child jobs. Then it marks the parent job as in-progress and moves on.
What I don't do is have the orchestrator execute anything directly. That was a mistake I made early. When the orchestrator both plans and executes, you get bloated context windows, compounding errors, and failures that are hard to debug because you can't tell where in the process things went wrong.
Separation of planning and execution is the single most important structural decision in this whole setup.
The Specialist Agent Layer
Below the orchestrator are specialist agents. Each one has a narrow job and a tight system prompt. They don't know about the other agents. They just pick up tasks assigned to them, do the work, and write the output.
The agents I run permanently in my stack are these.
The Research Agent. Pulls information from specified sources, structures it into a brief, writes it to a Notion database row. Used for client research, competitor scans, topic research for content.
The Drafting Agent. Takes a brief and produces a first draft. Content, proposals, emails, documentation. Output goes to a specific folder in our file system, tagged with job ID.
The Review Agent. Takes a draft, checks it against a rubric, returns a structured critique with specific revision suggestions. Does not rewrite. Just reviews. Keeping review and rewrite separate keeps the feedback clean.
The Code Agent. Handles narrow, well-specified code tasks. Bug fixes, small feature additions, test generation. Works inside a sandboxed repo environment. All output goes to a branch, never directly to main.
The Communication Agent. Drafts client-facing messages based on job status updates. I review these before they send. This is a hard rule. Agents don't send external communications without a human in the loop.
Where I Stay In The Loop
Fully automated doesn't mean unreviewed. I have deliberate checkpoints where work surfaces to me before it moves forward.
Anything client-facing stops for my review. Period. Drafts go to a Notion inbox. I approve or revise before the communication agent sends anything. Takes me about ten minutes in the morning.
Anything going to a production environment stops for my review. Code PRs are opened automatically, but I merge them. The agents can write the code. They don't deploy it.
Anything the orchestrator flags as ambiguous stops for my review. If the job spec doesn't have enough information to decompose cleanly, the orchestrator writes a question to a needs-clarification queue and pings me in Slack. I answer the question, it continues.
Everything else runs. First drafts, research briefs, internal documentation, reports, test suites, structured data, meeting summaries. All of that completes without me touching it.
The Failure Modes and How I Handle Them
This architecture breaks in three specific ways.
Agent hallucination in the task plan. The orchestrator sometimes produces subtasks that don't map to real agent capabilities, or breaks a job into steps that aren't actually sequential. Fix: the orchestrator's system prompt includes the exact list of available agent types and what each one can receive as input. When I add a new agent, I update the orchestrator prompt immediately.
Context drift on long jobs. If a job has more than five subtasks, the agents working downstream don't have enough context to produce coherent output. Fix: jobs with more than five subtasks get split into two parent jobs at the orchestration layer. Smaller batches, cleaner output.
Queue pileup during high-volume periods. When lots of triggers fire at once, jobs stack up and the five-minute poll cycle creates delays. Fix: I have a priority field in the queue. Client jobs get priority one and run immediately. Internal jobs get priority two and run on the standard cycle. The orchestrator checks for priority one jobs first on every poll.
The Actual Impact on How I Work
Before this setup, my mornings started with me figuring out what needed to happen that day. Now they start with me reviewing what already happened overnight.
Research briefs are in Notion. Drafts are in the folder. Questions that need answers are in my Slack. The queue shows me what's in progress, what's done, what needs me.
I'm not doing less work. I'm doing different work. The operational work is handled. My time goes to decisions, creative direction, and client relationships. That's the actual value of this architecture. Not magic automation. A clean separation between the work that needs me and the work that doesn't.
Build the queue first. Get your triggers set up. Start with one orchestrator and two specialist agents. See what completes without you. Then expand from there.
The goal isn't to remove yourself from your business. It's to stop being the bottleneck in it.
