Multiagent orchestration is what happens when more than one LLM cooperates on a task with explicit coordination between them. The key word is explicit. A single agent that calls fifteen tools in a ReAct loop is not multiagent, even if some of those tools happen to be other models. What makes a system multiagent is that you, the system designer, have decided that distinct agents exist, that they have distinct roles or contexts, and that there are rules for how they hand work between each other. The stakes are simple. Single-agent loops hit a ceiling on long-horizon tasks because context windows fill up, instructions blur, and one bad tool result poisons every subsequent decision. Multiagent setups try to dodge that ceiling by splitting work across fresh contexts. Whether they actually do is the whole question.
The honest pitch is parallel research, separation of concerns and context isolation. If you can spin three subagents on three slices of a research problem at once, you cut wall-clock time and you let each one keep a clean window focused on its slice. Role specialization is the other half. A planner writing a brief, an executor doing the actual work, and a critic checking the output are three very different prompts, and squishing them into one agent tends to produce a model that is mediocre at all three. Context isolation also blunts prompt-poisoning attacks and stops upstream junk from leaking into downstream reasoning. The cost is real though. Anthropic’s own writeup on their research system pegs the token cost at roughly fifteen times a single-agent chat, and latency goes up with every coordination hop. Multiagent is not free, and you should not reach for it before you have a single-agent baseline that is genuinely stuck.
There are maybe five coordination patterns that keep showing up, and most production systems are a mix of two or three of them.
The thing worth internalizing is that the pattern names describe how control flows, not what the agents do. You can have an orchestrator-worker system of debaters, or a pipeline of swarms. Pick the coordination shape that matches the task’s dependency structure, then pick roles.
The framework picture has churned a lot in the last year, so it’s worth grounding in what each one actually offers as a coordination primitive.
Worth a one-line mention for completeness: Google’s ADK 2.0 ships a code-first SDK with a graph-based Workflow Runtime and A2A delegation, and AWS Strands is a model-first SDK that AWS uses internally for Amazon Q Developer and AWS Transform, with built-in Swarm, Graph and Workflow patterns plus OTel observability.
If you forced me to compress the current consensus into a checklist, it looks like this.
Anthropic’s “Building Effective Agents” made the workflow-vs-agent distinction explicit back in late 2024, and it has aged extremely well. Most production “agent” systems are workflows with one or two genuinely agentic steps.
The ways these systems break are pretty consistent across frameworks.
Start single-agent with good tools and good prompts, and measure where it falls over. If the failure mode is context window exhaustion on long research, reach for orchestrator-worker. If it is one agent juggling too many roles, split into planner and executor before you split into a crew of seven. Most teams that adopt a multiagent framework end up using maybe two of its features and would have been fine with a smaller setup. The frameworks are good, but the question to answer first is whether you have a problem they solve.
Most of what I learned writing this is that the frameworks converged faster than the vocabulary did. The interesting work in 2026 is not picking sides, it is figuring out which parts of your system genuinely need a model and which parts just need code.
]]>One thing I realised about myself is that I tend to enter into a state of what I call “stasis” when many things that matter compete for my limited attention and time. And here’s what “stasis” is about:
When something upcoming matters significantly to you, what goes on in your mind? Does it occupy a little corner in your head, making you question if you are fine?
I realise that things that I worry about tend to stay rent-free like an overdue tenant.
I’ll mostly write about:
This is just the beginning. If you’re reading this, thanks for stopping by. Stick around — there’s more to come.
]]>This blog wasn’t hand-coded line by line in the traditional sense. I used Claude Code as my development partner throughout the entire process. Here’s what that looked like:
The combination meant I could focus on what I wanted rather than how to implement it. I still made all the design decisions, but the execution was dramatically faster.
I wanted something that:
Jekyll checks all the boxes. It’s been around forever, has great docs, and GitHub Pages supports it natively. It’s also a great fit for AI-assisted development since the project structure is clean and predictable.
The site ships with three themes — dark, light, and a warm beige (coffee) mode. The dark theme uses near-black backgrounds with cyan accents:
:root {
--bg: #0a0a0f;
--surface: #12121a;
--accent: #00d4ff;
--text: #e0e0e0;
}
Cards use a glassmorphism-inspired look with subtle borders and glow effects on hover. Typography is set in Inter for body text and JetBrains Mono for code blocks.
_layouts/ → HTML templates (default, post, page)
_includes/ → Reusable components (nav, footer, post cards)
_posts/ → Blog posts in Markdown
_data/ → YAML data files (projects, tags)
assets/css/ → Stylesheet
Everything compiles to a _site/ folder that GitHub Pages serves.
If you want to build something similar, feel free to check out the source code — it’s all open source.
]]>I’m Marcus, and this is where I’ll be sharing my thoughts on tech, code, projects, and whatever else catches my attention. I’ve been meaning to start writing for a while now, and here we are.
A few reasons:
I’ll mostly write about:
This is just the beginning. If you’re reading this, thanks for stopping by. Stick around — there’s more to come.
]]>