arthai-marketplace

Architecture: Skills, Agents, Hooks, and the Orchestrator

arthai turns one generalist assistant into a coordinated team. Understanding the four moving parts — and why work flows between them the way it does — explains most of the toolkit’s behavior.

The three building blocks

Layer What it is When it acts
Skills Slash-command workflows that encode multi-step engineering sequences — /fix runs root-cause analysis, scope lock, fix, regression tests as one process When you (or a hook, or another skill) invoke them
Agents Specialists spawned by skills, each pinned to the right model tier for its job — QA, SRE, frontend, backend, planning, research While a skill is running, often several in parallel
Hooks Automatic behaviors at session lifecycle events — guards that block rm -rf and force-pushes, routers that classify your message, telemetry that records every span On every prompt, tool call, or session event, without being asked

The division of labor: skills own process (the sequence, the checkpoints, the artifacts), agents own execution (the actual reading, writing, testing), and hooks own the ambient layer (safety, routing, observability) that neither has to remember to do.

A skill like /implement is therefore not “an agent” — it’s a script for a team: it spawns backend, frontend, and QA agents in parallel, has a red team challenge their output, and chains into /qa and /pr. The full inventory: skills reference, agents reference, hooks reference.

The orchestrator and triage model

Your main Claude Code session is the orchestrator. It doesn’t do everything itself — it decides, per message, whether to act directly or delegate to the toolkit.

Two hooks inform that decision on every message you send:

The principle is the same one a senior engineer applies: delegate routine, repeatable work; keep judgment, novel problems, and architecture for yourself.

flowchart TD
    U([Your message]) --> H["Hooks fire first<br/>triage-router · intent-classifier · guards"]
    H --> O{Orchestrator<br/>decides}
    O -- "quick lookup, small edit" --> D["Direct tools<br/>(read, edit, search)"]
    O -- "multi-step workflow" --> S["Skill<br/>e.g. /fix, /implement, /qa"]
    S --> A1["Haiku agents (1x)<br/>explore, scan, triage"]
    S --> A2["Sonnet agents (7x)<br/>build, test, review"]
    S --> A3["Opus agents (50x)<br/>architecture, PRD debate"]
    H -. telemetry spans .-> AI[("Arth Intelligence<br/>local dashboard")]

Model tiers — the cost logic

Every agent runs at one of three tiers, and the relative cost is roughly Haiku 1x · Sonnet 7x · Opus 50x — the same multipliers the Arth Intelligence dashboard displays per agent spawn.

The assignment principle is match the tier to the stakes of being wrong:

Some agents use inherit — they take whatever tier their caller is running, on the logic of “review me with the same power that produced the work” (e.g. code-reviewer).

This is why a toolkit session is typically cheaper than improvising the same work at a single premium tier: the expensive model is reserved for the few decisions that deserve it, while the bulk of tool calls run at 1x–10x. The per-agent tier assignments are visible in the agents reference, and every spawn’s actual tier and cost shows up in the dashboard.