01, Parent Agent / Dispatcher
Orchestrator
Plans the run, routes tasks, and enforces policy checkpoints before sub-agents act.
Future Ops · Demo
Agent Starter.
This demo shows how specialized agents collaborate in one shared workflow. Tasks are routed automatically, context stays synchronized, and approvals keep the process transparent and controlled.
OpenCode Orchestrator
Demo
Agent Network
Top-Down DelegationOrchestrator
Parent Agent / Dispatcher
Council
Optional Multi-Model Review
Oracle
Architecture Review
Councillor
Read-only Advisor
Explorer
Codebase Discovery
Librarian
Context & Docs
Designer
UI/UX & Polish
Fixer
Patch & Resolve
Activity Stream
Simulated Live02The roster
Specialised agents that work together.
Top-down delegation: the Orchestrator plans, sub-agents act inside their lane, and every hand-off is observable.
02, Optional Multi-Model Review
Council
Cross-checks high-stakes decisions across multiple models before a result is committed.
03, Architecture Review
Oracle
Inspects structural decisions and surfaces risk before scope expands.
04, Read-only Advisor
Councillor
Provides guidance and second opinions without write access to systems of record.
05, Codebase Discovery
Explorer
Walks the repository or workspace to assemble the context the orchestrator needs.
06, Context & Docs
Librarian
Curates documentation, prior decisions, and reference material for every hand-off.
07, UI/UX & Polish
Designer
Handles interface decisions, copy polish, and the last-mile presentation layer.
08, Patch & Resolve
Fixer
Closes the loop: applies the change, reruns checks, and reports outcomes back upstream.
Orchestration is a design choice, not magic.
Want to explore agent workflows for your operations?
FAQ
Questions,
straight.
Questions about this Agent Starter demo and multi-agent orchestration. If yours isn’t here, ask us directly.
What am I looking at on this page?
A visualisation of how multiple specialised agents can run under one orchestrator: routing work, sharing context, and surfacing activity in a single stream. It illustrates patterns we use when designing governed agent workflows for clients, not a live product tied to your systems.
Is this a production deployment?
No. The activity stream is simulated to show timing and hand-offs. A production setup connects to your APIs, identity, logging, and approval rules, and is scoped and tested like any other integration.
Why use an orchestrator instead of one large prompt?
Smaller, focused agents are easier to test, observe, and swap. An orchestrator decides what runs next, what context each step gets, and where humans must approve, which improves reliability and auditability compared with a single monolithic call.
Can the roles (Explorer, Librarian, etc.) match our org?
Yes. Names and responsibilities here are examples. In a real engagement we map agents to your processes, e.g. research, drafting, compliance check, CRM write-back, and wire only the integrations you need.
How does this relate to OpenCode or other stacks?
This page is branded around an OpenCode-style orchestrator as a conversation starter. Under the hood, similar patterns apply across tools: explicit routing, structured outputs, guardrails, and traceability, regardless of vendor.
What would a first step look like with SMAPAS?
We usually start with one high-friction process, clear KPIs, and a short pilot. You get a working slice with logging and approvals, then we decide together whether to widen scope or adjust architecture.