# Agents

SEED Harness has one professor-facing OpenCode agent:
`lab-representative`.

Normal users should start work through `/seed` and talk to
Lab-Representative. They should not need to select or manage internal workers
by hand.

## Runtime Surfaces

| Surface | Role |
|---|---|
| `lab-representative` | The public SEED face. It receives professor goals, creates run state, decides whether a dynamic team is needed, coordinates tools, evidence, progress, and final reporting. |
| Dynamic role ids | Per-run team members authored by Lab-Representative inside an inline team spec, such as `scope-mapper`, `api-implementer`, or `claim-verifier`. These are the meaningful worker identities inside a run. |
| Project config | Current installs expose only `lab-representative` in OpenCode. Internal worker identities live in SEED run artifacts, not in OpenCode's global agent selector. |

The actual team for a professor task is always the accepted dynamic team spec
stored under `.seed-agent/runs/<run_id>/team/specs/`. The core does not create a
paper-review, web-app, automation, or research-framework team from keywords,
file extensions, or PDF paths.

## Dynamic Member Contract

For substantial work, Lab-Representative should write an explicit inline team
spec. Each member contract can define:

- `role_id` and `role_label`
- mission prompt and stop condition
- abstract `capability_profile`
- allowed and denied `seed_*` tools
- MCP and skill policy
- read paths and write paths
- evidence obligations and expected outputs

SEED validates the spec before launch. For larger tasks, validation expects
planner/executor/verifier coverage unless the task is intentionally small.

After launch, each dynamic member gets an OpenCode child session. SEED
reinjects the durable member contract into later model turns and compaction
context, so a long-running member does not depend only on the first prompt
staying in context.

## Child Sessions

OpenCode child sessions still require a concrete agent id. SEED uses
`lab-representative` as that runner and injects the accepted dynamic member
contract into the child session prompt and later context transforms. The
professor-facing concept is:

```text
professor task
  -> Lab-Representative
  -> explicit dynamic member contracts
  -> child sessions that receive those contracts
```

Use the role id in the team spec when reasoning about a run. The OpenCode agent
selector is intentionally not the team roster.

## Permissions

Permissions are contract-specific, not just persona-specific. Member sessions
are checked against durable `allowed_tools`, `denied_tools`, and `write_paths`
before SEED tool execution.

Reviewer-like members normally receive read-only contracts. Implementer-like
members can receive bounded write paths. Experimenter-like members can receive
check/script tools. Recursive delegation and team expansion are reserved for
Lab-Representative unless a member contract explicitly allows them.

Workspace writes are also guarded by leases and conflicts. Overlapping
exclusive writes and stale base hashes create durable conflict records instead
of silently overwriting another member's work.

## TUI Identity

If asked to introduce itself, Lab-Representative should answer as the SEED Lab
representative: it receives professor goals, coordinates internal lab
members/tools/experiments/review, and returns final deliverables.

If OpenCode does not open on `Lab-Representative`, rerun:

```bash
npx @seed-lab/opencode-seed-agent@latest install --project
```

That normalizes the project config to the current single-agent shape.
If `Build` or `Plan` still appear as primary user faces after reinstall, look
for inherited parent OpenCode config such as
`../.opencode/opencode.jsonc` or `C:\.opencode\opencode.jsonc`; OpenCode merges
parent project configs before starting the TUI.
