Agentic Backend
Comparable to: LangGraph, CrewAI, AutoGen, Letta
Key Concepts
Use the concepts below when they fit the task. Not every agentic workflow needs all of them.
- Each agent is a registered function with a single responsibility
- Agents communicate via named queues (ordered handoffs) and shared state (accumulated context)
- Approval gates are explicit checks in the producing agent before enqueuing the next step
- An HTTP trigger provides the entry point; agents chain from there
- Pubsub broadcasts completion events for downstream listeners
Architecture
HTTP request
→ Enqueue(agent-tasks) → Agent 1 (researcher) → writes state
→ Enqueue(agent-tasks) → Agent 2 (critic) → reads/updates state
→ explicit approval check (is-approved?)
→ Enqueue(agent-tasks) → Agent 3 (synthesizer) → final state update
→ publish(research.complete)
iii Primitives Used
| Primitive | Purpose |
|---|
registerWorker | Initialize the worker and connect to iii |
registerFunction | Define each agent |
trigger state::set, state::get, state::update | Shared context between agents |
trigger({ ..., action: TriggerAction.Enqueue({ queue }) }) | Async handoff between agents via named queue |
trigger({ function_id, payload }) | Explicit condition check before enqueuing |
trigger({ function_id: 'publish', payload, action: TriggerAction.Void() }) | Broadcast completion to any listeners |
registerTrigger({ type: 'http' }) | Entry point |
Reference Implementation
See ../references/agentic-backend.js for the full working example — a multi-agent research pipeline
where a researcher gathers findings, a critic reviews them, and a synthesizer produces a final report.
Common Patterns
Code using this pattern commonly includes, when relevant:
registerWorker(url, { workerName }) — worker initializationtrigger({ function_id, payload, action: TriggerAction.Enqueue({ queue }) }) — async handoff between agents- trigger
state::set, state::get, state::update — shared context between agents
- Explicit condition check via
await iii.trigger({ function_id: 'condition-fn', payload }) before enqueuing next agent
trigger({ function_id: 'publish', payload: { topic, data }, action: TriggerAction.Void() }) — completion broadcast- Each agent as its own
registerFunction with agents:: prefix IDs
const logger = new Logger() — structured logging per agent
Adapting This Pattern
Use the adaptations below when they apply to the task.
- Replace simulated logic in each agent with real work (API calls, LLM inference, etc.)
- Add more agents by registering functions and enqueuing to them with
TriggerAction.Enqueue({ queue })
- For approval gates, call a condition function explicitly before enqueuing the next agent
- Define queue configs (retries, concurrency) in
iii-config.yaml under queue_configs
- State scope should be named for your domain (e.g.
research-tasks, support-tickets)
functionId segments should reflect your agent hierarchy (e.g. agents::researcher, agents::critic)
Engine Configuration
Named queues for agent handoffs are declared in iii-config.yaml under queue_configs. See ../references/iii-config.yaml for the full annotated config reference.
Pattern Boundaries
- If a request is about adapting existing HTTP endpoints into
registerFunction (including prompts asking for { path, id } endpoint maps + loops), prefer iii-http-invoked-functions.
- Stay with
iii-agentic-backend when the primary problem is multi-agent orchestration, queue handoffs, approval gates, and shared context.
When to Use
- Use this skill when the task is primarily about
iii-agentic-backend in the iii engine.
- Triggers when the request directly asks for this pattern or an equivalent implementation.
Boundaries
- Never use this skill as a generic fallback for unrelated tasks.
- You must not apply this skill when a more specific iii skill is a better fit.
- Always verify environment and safety constraints before applying examples from this skill.
