What Zari-Zardozi Teaches Us About Agent Coordination
In a Zari-Zardozi workshop in Old Delhi, six artisans work on a single bridal dupatta. One creates the base pattern. Another applies the metallic thread. A third adds sequins. A fourth handles the edge work. They don’t talk much. They don’t pass the fabric in strict sequence. Yet the final piece is coherent—every motif aligned, every border continuous, every layer building on the last.
This is not romantic craft nostalgia. This is a coordination architecture that’s been production-tested for 400 years.
I’m calling this pattern Layered Autonomy—not because the world needs another framework, but because most multi-agent AI systems fail at exactly what Zari-Zardozi solves: how to give workers genuine autonomy while maintaining system-level coherence.
We’re Building Agent Systems Wrong
The dominant pattern is the command-and-control planner: a central orchestrator that assigns tasks, waits for results, then decides the next step. It’s sequential. It’s brittle. It doesn’t scale.
At Ostronaut, we initially built exactly this architecture. A central planner that coordinated a fleet of specialist agents to generate training content—slides, videos, quizzes. The planner would call one agent, wait for output, call the next, wait again, then call the quality checker. Linear dependency chains everywhere.
It worked for simple cases. It collapsed under complexity.
The problem wasn’t the agents. The problem was the coordination model. We were building assembly lines when we needed something closer to a Zari workshop.
Layered Autonomy is the alternative: agents work in parallel on shared context, with loose coupling and tight coherence. Not through constant communication. Through shared understanding of the end state.
Four Lessons from the Embroidery Floor
Here’s the falsifiable claim: Agent systems that implement layered autonomy—where workers operate on shared context with clear role boundaries but loose temporal coupling—will outperform planner-orchestrated systems on tasks requiring iterative refinement by at least 40% in both speed and quality.
The Zari-Zardozi model teaches four specific lessons:
1. Specialization Without Silos
In a Zari workshop, the nakshi maker creates patterns. The zari worker applies metallic thread. The sequin specialist adds embellishments. Each role is distinct. But they’re not isolated—every artisan understands the full design.
Most agent architectures get this wrong. They create specialists (a content agent, a research agent, a quality agent) but treat them as black boxes. The planner knows what each agent does. The agents don’t know about each other.
This creates artificial dependencies. The content agent can’t start until research is “done.” The quality agent can’t run until content is “complete.” You’ve built specialists, but you’ve also built a bottleneck.
The Zari model is different. The zari worker doesn’t wait for the nakshi maker to finish the entire pattern. They work on completed sections while new sections are still being drawn. Parallel execution on shared context.
3. Iterative Refinement Over Perfect Planning
Zari-Zardozi work proceeds in layers. Base stitch first. Then zari. Then sequins. Then finishing touches. Each layer builds on the last. Each layer can be evaluated independently.
The master craftsperson doesn’t plan every stitch upfront. They plan the overall design, then let each layer emerge.
Most agent planners do the opposite. They try to decompose the entire task upfront into a perfect sequence of subtasks. This fails for two reasons:
First, you can’t know what subtasks you’ll need until you see the results of earlier work. If the structure agent generates a complex nested outline, the content agent might need to split its work differently than if the outline is flat.
Second, perfect planning is expensive. You spend tokens and time trying to predict every edge case, when you could just execute and adapt.
The Zari model: plan the layers, not the stitches. In agent terms: define the phases (structure → content → quality → assets), but let agents decide how to execute within their phase.
4. The Master as Orchestrator, Not Micromanager
The ustad (master craftsperson) in a Zari workshop doesn’t do the embroidery. They ensure coherence. They check alignment. They decide when a layer is ready for the next phase.
This is not a planner in the traditional sense. The ustad doesn’t assign every task. They maintain the quality bar and the overall vision.
In agent architectures, this means: the orchestrator’s job is to manage transitions between layers, not to micromanage within layers.
Our current Ostronaut orchestrator does three things:
- Validates that each layer meets quality gates before the next layer starts
- Handles failures by deciding whether to retry or skip
- Maintains the audit trail of what happened and why
It doesn’t decide which specific content to generate or which specific assets to create. That’s the workers’ job.
The Performance Difference
Old architecture (planner-orchestrated):
- Fully sequential—zero parallelization
- Frequent timeouts from long dependency chains
- Every new content type required rewriting the planner’s logic
New architecture (layered autonomy):
- Agents overlap—structure and content generation run concurrently where possible
- Failures are isolated to individual layers instead of cascading
- New content types require a new specialist agent and a validation gate—the orchestrator doesn’t change
The speed improvement matters. But the bigger win is adaptability. When we added a new content type (interactive games), the old architecture required rewriting the planner’s task decomposition logic. The new architecture required adding a new worker agent that knows how to operate on the shared state. The orchestrator didn’t change.
This is the Zari-Zardozi lesson: when you add a new type of embellishment to the craft, you don’t retrain every artisan. You bring in a specialist who understands the shared language of the fabric.
The Pattern
Most teams building multi-agent systems are building assembly lines. Sequential. Rigid. Optimized for predictability.
The Zari-Zardozi model suggests a different architecture: shared context, layered execution, loose coupling, tight coherence.
This isn’t a metaphor. It’s a specific architectural pattern:
| Planner-Orchestrated | Layered Autonomy |
|---|---|
| Agents call each other sequentially | Agents operate on shared state in parallel |
| Planner decides all subtasks upfront | Orchestrator manages phase transitions only |
| Failure in one agent blocks the chain | Failure in one agent is isolated to its layer |
| Adding new capabilities requires replanning logic | Adding new capabilities requires new worker + validation gate |
The hard part isn’t building the agents. The hard part is building the coordination layer—the equivalent of the fabric that Zari artisans work on.
For us, it’s a structured representation of the content being generated. For other systems, it might be a knowledge graph, a vector store, or a shared document. The specific technology matters less than the principle: give agents shared context, clear boundaries, and the autonomy to execute within their layer.
What I don’t know yet: how to build trust in systems where no single agent “owns” the output. When something goes wrong, users want to know which agent failed. In a layered system, failure is often emergent—the output is coherent at each layer but incoherent overall.
The Zari workshop solves this through the master craftsperson’s eye. They can see when the overall composition is off, even if each individual element is well-executed.
We don’t have a good equivalent yet. Validation gates catch obvious failures. But subtle incoherence—content that’s technically correct but doesn’t serve the learning objective—still slips through.
More on this as I work through it.