Agents

Default and community packs

Every space starts with four roles already in the graph. The community gallery carries discipline packs you add on top. A pack is roles only: what to read, which gates to run and where the role may touch are yours to fill.

What every space starts with

When a personal graph is created at first sign-in, and when a team graph is created with the team, the Default Agents pack is written into it. Four roles, each a concept under vinc/agent, with the handoffs between them as edges. They appear in prompts/list at once, so a host connected to a fresh space already has a roster.

steward
concept:agent-steward · knowledge

Keeps conventions, duplicates and topics honest. Proposes merges and retopics with evidence and never applies them. Deleting, merging and ratifying stay with a person.

researcher
concept:agent-researcher · knowledge

Measured research that ends in a document, its concepts and an episode. Assembles what a decision needs, and never takes the decision.

curator
concept:agent-curator · execute

Takes documents in: stores the source with vinc_doc_put, previews extraction, links mentions, proposes one topic per document. Applying an extraction and approving a topic are a person's.

reviewer
concept:agent-reviewer · verify

Checks every claim against the graph and labels it cited, assumed or unsourced. Never edits, never escalates: it returns the work to its author.

vinc/agent is a reserved topic. It does not count toward the free tier's five topics, so the four default roles cost you no topic at all.
If the four are missing (a space made before this shipped, or a deployment whose gallery lacks the official pack), install Default Agents from the community gallery. Import is idempotent: the four MERGE by id, and importing twice still leaves four.

Why these four, and why no orchestrator

The default set holds only what any graph needs regardless of what it is about: someone to keep conventions and topics honest, someone to research, someone to take documents in, someone to check claims. Nothing about software, design or operations, because a graph about a novel or a garden has none of that.

And there is no orchestrator anywhere, in this pack or in the discipline packs. The graph is not the scheduler. Which role runs, when and where is the runtime's business, and the order between roles is already on the edges. Where an orchestrator is needed, the runtime at that seat is the orchestrator.

Discipline packs

Four official packs in the gallery. Each carries three to five roles and the handoffs between them. Install any of them, and mix them: every pack keeps its edges inside itself, so two installed together do not step on each other.

Software Agentsdeveloper · gate-runner · reviewer-checklist · reviewer-judgement · security. The developer changes, the gate runner runs, two reviewers read, security hands findings over as packages.
Design Agentsdesigner · design-reviewer · design-researcher. Values in the token file, reasons in the graph. The reviewer measures contrast and drift; the researcher turns interviews into records.
Infra and Ops Agentsinfra · ops · release. One writes the declaration and stops at plan, one diagnoses and never changes state, one prepares what a person publishes.
Copy and Marketing Agentscopy-writer · copy-owner · marketing. One drafts lines for review, one ships only lines read aloud, one ties every claim to the build it is true on.
Community import writes to your personal graph today. A team graph receives the default pack when it is created; installing a discipline pack into a team is not available yet.

Make the roles yours

Every role in a pack arrives with empty reads, gates and paths, and a tool_note that says so. Fill them: reads are your own canon document ids in the order to read them, gates your repository's gate commands, paths what the role may touch.

vinc_ingest
{
  "nodes": [{
    "id": "concept:agent-developer",
    "type": "concept",
    "props": {
      ...the stored props, read back first, then:
      "reads": ["your.canon.architecture", "your.canon.repo-workflow"],
      "gates": ["scripts/gate_lint.py", "scripts/gate_citations.py"],
      "paths": ["src/", "tests/"]
    }
  }, {
    "id": "decision:agent-developer-reads-and-gates",
    "type": "decision",
    "title": "The developer role reads two canon documents and runs two gates",
    "props": { "replaced": { "reads": [], "gates": [] } }
  }],
  "edges": [{ "from": "decision:agent-developer-reads-and-gates",
              "to": "concept:agent-developer", "type": "about" }]
}
props is replaced whole on every write. To add one key, read the stored value first (with vinc_graph, or from the previous write's stored) and send the merged object. And a change to reads, gates or never travels with one decision:agent-<role>-<change>. The rest is on Roles and orchestration.

Publish your own

A pack of roles is a pack like any other. In the app, make a pack from Packs with the vinc/agent domain as its scope, then publish it from Community. On the receiving side the roles land in that person's vinc/agent under their ids as they are. So name an id for what the role is, not for who made it, and know that an id shared with another pack means the later install overwrites the earlier one's props whole.

Read on