Whitepaper / Execution Layer

Ghast Agent Team

Agent Team is a Ghast Workbench feature for coordinating specialized agents around one shared outcome. It provides task ownership, handoffs, review, completion conditions, and human checkpoints.

Chat suits a single question and Coding suits one local project. Agent Team is for work that needs several kinds of expertise and more than one owner, such as a competitive analysis that combines research, financial modelling and writing, or a code change that needs implementation, tests and documentation. Ghast introduced the feature on 3 September 2026, and the Team guide covers the controls step by step.

Operating model

When a user submits a complex objective, the team can establish a work plan covering:

1. Ownership and roles: a lead agent owns the final outcome while specialized agents handle defined areas of work.
2. Tasks and outputs: each assignment has a bounded scope and an expected artifact or result.
3. Dependencies and handoffs: one member’s output can become another member’s input through an explicit transfer.
4. Review and completion: required checks and completion conditions determine when the work can be closed.

The lead agent integrates the work into a coherent final delivery. Other agents complete concrete assignments within their domains.

The revision loop is what separates a team from a pipeline. When a check fails, the work goes back to the specialist who owns it, instead of being quietly absorbed into the final result.

A worked example

Suppose a product manager asks for a pricing-page update for a new plan. The lead agent splits the objective into three tasks:

• Research. A research agent compiles competitor pricing from approved sources and hands over a comparison table.
• Copy. A writing agent drafts the page copy from that table and the product brief.
• Implementation. A coding agent, which could be a local agent such as Claude Code already running on the user’s machine, implements the page in the project repository and runs the tests.

Each handoff is explicit: the copy cites the research table, and the implementation uses the approved copy. When review finds that one competitor price is out of date, the item goes back to the research agent rather than being patched in the copy. The team pauses once to ask the product manager whether to show annual or monthly prices first, because that is a business decision. The final delivery is the merged change, the copy and the source table, returned together for acceptance.

Working modes

Direct keeps a one-to-one conversation with one specialist from becoming a brief for everyone else. Roundtable is useful when the question is contested, for example whether to build or buy a component. Independent answers surface the real disagreement, and the lead has to resolve it explicitly instead of averaging it away. Assign work gives every item one accountable owner and a visible status: open, in review or done. Review returns the files with the result, so acceptance is based on the artifact rather than a summary of it. Local agents bring coding tools such as Codex and Claude Code into the team, where they keep their own sessions and the permissions the user has already granted them.

Shared context and role boundaries

Team members work from shared task context while retaining role-specific workspaces. They can read, cite, test, challenge, or respond to another member’s work, preserving substantive disagreement until it has been reviewed and resolved.

Both halves matter. Shared context covers the objective, the assignments and the artifacts the team is allowed to see. Without it, the lead cannot integrate the work. Separate workspaces keep each member’s changes attributable. Without them, a handoff has no boundary and a reviewer cannot tell whose change they are looking at.

Human checkpoints

Users remain part of the workflow. The team can pause for missing information, competing valid directions, or decisions that require business judgment. A user can provide context, change the goal, redirect work, assign a member, or approve a checkpoint.

A pause is a normal state, not a failure. Agents can produce work quickly, but someone still has to own the decisions the work depends on. Checkpoints keep a person accountable for the final result without making them supervise every step.

Relationship to Capabilities

Agent Team coordinates work inside the Workbench. A Capability represents a specific service from that work under Ghast Protocol’s commercial and accountability model.

A team that runs the same kind of job repeatedly, with the same roles and the same review checks, has the shape of a service. The software security review in Capability Examples is one: static-analysis, dependency-review and findings-validation agents, with a lead agent owning the report. Packaging that work as a Capability, which is part of Ghast Protocol and in development, adds what a team cannot provide by itself. That means a written claim a stranger can rely on (Defined Claims), evidence that shows delivery (Evidence and Verification), and accountability if the claim is missed (Challenges and Disputes).

The team’s playbooks, prompts and review rules would stay with the Creator, as the Privacy Model sets out. See Capability Definition for the unit itself, and System Overview for one workflow followed from Workbench to a Capability.