Hey Vivia

Shared project graph

People and coding agents, working from the same project graph.

Vivia connects tasks, dependencies, decisions, notes, and execution records so each next move starts with project context.

Create a workspace Inspect the workflow
Graph Ledger / API claim safety Settled · human review
Illustration of a project graph. Sample data; not a live workspace.

Relationship record

  • API-42 depends_on DB-17
  • MCP-31 depends_on API-42
  • DOC-08 relates_to API-42
  • DEC-12 constrains API-42
  • NOTE-21 records_note API-42
  • RUN-94 records execution evidence for API-42
  • REV-03 requests human review of API-42

Fragmented evidence

Fast sessions leave partial truth behind.

Chats, trackers, notes, and code each preserve a fragment. None alone carries the connected project state the next person or agent needs.

Connection stops here: there is no shared model linking instruction, state, and decision.

Agent session / 14:06

Keep claim retries safe for older MCP clients.

The instruction names a constraint, but not the decision that made it authoritative.

API-42 / in progress

Make task claims idempotent.

The tracker keeps status while dropping the dependency that established readiness.

DEC-12 / accepted

Use lease tokens for repeated claims.

The decision survives without an explicit relation back to API-42.

Connected unit of work

A task carries the project around it.

A task is not only a title and status. It is a bounded record of why the work exists, what constrains it, what it depends on, and what happened when an external harness performed it.

Sample task · derived ready → in review

API-42 / Make task claims idempotent

One stable task. Six typed relations. Selection changes emphasis and evidence, never the task geometry.

Relationship field / fixed geometry

IntentOne active claim ConstraintBackwards compatible depends_onDB-17 / done constrained_byDEC-12 / accepted records_noteNOTE-21 / recorded evidence_fromRUN-94 / external harness Task / in reviewAPI-42Idempotent claims
01 · Intent

One claim per active lease.

Repeated requests for the same task and actor return the existing active claim instead of creating competing execution records.

same actor + active lease → same claim

02 · Constraints

Keep existing MCP clients compatible.

The response retains the current task reference and adds conflict detail without changing existing successful claim fields.

DEC-12 · lease semantics are authoritative

03 · Dependencies

Readiness follows the graph.

API-42 depends_on DB-17. DB-17 completing causes API-42 to become ready. Downstream, MCP-31 depends_on API-42.

DB-17 done → API-42 ready → MCP-31 unblocked later

04 · Decisions

Lease expiry permits a new claim.

DEC-12 constrains API-42: an active lease is idempotent; an expired lease may produce a new execution record with explicit lineage.

active → reuse · expired → create with lineage

05 · Notes

Client retry guidance stays attached.

DOC-08 relates_to API-42 and explains that clients may retry a timed-out request without creating parallel active claims.

timeout → retry safely

06 · Execution record

Results return with evidence.

External harness results stay outside Vivia. An external harness records the execution result through an MCP client. RUN-94, recorded through an MCP client, links the summary, changed files, and test result to API-42 before REV-03 requests human review.

2 files changed · 18 tests passed · review requested

Coordination workflow

Work moves through six inspectable stages.

Every stage leaves a complete settled record. The sequence never advances itself, and a person remains responsible for review and redirection.

Graph / outcome boundary OUT-01Observable outcome API-42Draft task DB-17Draft task
Outcome / OUT-01

Define the outcome.

Safe, repeatable task claims are recorded as an observable result before implementation choices begin.

Constraint attached

Older MCP clients keep their current response shape.

  1. Person recorded outcome OUT-01.
  2. Initial task boundaries attached.
Graph / bounded work OUT-01Outcome DB-17Lease storage API-42Claim handler MCP-31Client result
Task set / 3 bounded records

Break it into tasks.

Schema, API, and client work inherit the outcome while keeping separate acceptance boundaries.

Scope check

API-42 changes the claim handler; DB-17 owns lease storage; MCP-31 owns the client result.

  1. Three tasks linked to OUT-01.
  2. Person confirmed task boundaries.
Graph / derived readiness DB-17Done API-42Ready · derived MCP-31Downstream
Dependency / API-42 depends_on DB-17

Map dependencies.

DB-17 completing resolves the blocking path. API-42 becomes ready because the graph records the direction explicitly.

Readiness derivation

DB-17 done → API-42 ready → MCP-31 remains downstream

  1. DB-17 completion recorded.
  2. API-42 derived as ready.
Graph / scoped claim Vivia coordination state PersonDirects scope API-42Claim recorded MCP clientScoped interface
Claim / API-42

Assign or claim work.

The bounded task and actor are recorded in Vivia. An authorized external harness receives scoped context through its MCP client.

Claimed context

Intent, constraints, dependency meaning, notes, and acceptance evidence travel with API-42.

  1. Actor claimed API-42 through an MCP client.
  2. Bounded context read from Vivia.
Graph / evidence return Vivia coordination state External harnessExecutes elsewhere MCP clientRecords result API-42In review RUN-94Evidence attached
Execution record / RUN-94

Record results and decisions.

The external harness reports changed files, tests, and DEC-12 through its MCP client; Vivia records that evidence beside API-42.

Returned evidence

2 files changed · 18 tests passed · DEC-12 attached

  1. External harness returned RUN-94.
  2. MCP client recorded evidence for review.
Graph / human gate RUN-94Evidence API-42In review REV-03Human review MCP-31Next directed work
Human gate / REV-03

Review and redirect.

A person inspects the task, decision, and execution evidence, then accepts the result or records the next constraint and direction.

Review options

Accept API-42, redirect it with a new constraint, or direct the next bounded task.

  1. Person reviewed RUN-94 and DEC-12.
  2. Direction returned to the project graph.

Product mechanics

Coordination lives in Vivia. Execution happens elsewhere.

The boundary is deliberate: durable shared state stays inspectable in Vivia while authorized tools and external harnesses perform work in their own environments.

01 / directs

People

Define outcomes, set constraints, inspect evidence, and decide where the project goes next.

  • Outcomes and acceptance
  • Review and redirection
Vivia boundary 02 / shared state

Vivia

Vivia holds the shared project graph and durable coordination state.

  • Tasks, dependencies, decisions
  • Notes and execution records
03 / interface

MCP clients and plugins

Read scoped context and write authorized updates through Vivia's supported interface.

  • Context out
  • Recorded updates back
04 / executes outside

External coding-agent harnesses

Execute in their own repositories, runtimes, sandboxes, and tools—outside Vivia.

  • Repository and tool access
  • Harness-owned execution

Scoped direction and contextPeople → Vivia → MCP client → external harness

05Return recordResults, notes, decisions, and evidence come back for inspection.

  1. People define outcomes, constraints, and review points.
  2. Vivia holds the shared project graph and durable coordination state.
  3. MCP clients and plugins read and update that scoped state.
  4. External coding-agent harnesses execute in their own repositories and tools.
  5. Results, notes, decisions, and evidence return to Vivia for inspection.

Connected context ledger

Connected context changes what the next move can know.

The distinction is not a checklist of features. It is whether project meaning stays connected across sessions, tools, people, and agents.

How four coordination models preserve project context
Criterion Isolated chat Traditional tracker Ad hoc agent instructions Vivia
Durable project context Available only inside the session unless copied forward Persists fields and comments while context stays split across links Reconstructed inside each handoff prompt One durable graph connects work, decisions, notes, and evidence
Explicit dependency meaning Rephrased manually inside each session Often implied by status, ordering, or untyped links Embedded in one prompt and restated later Directional relations attach required work to the shared graph
Derived ready and blocked state Reconstructed from conversation history Status can change without explaining the graph cause Assumed from the latest handoff Readiness follows task state and explicit dependency conditions
Decisions attached to work Decision provenance is buried in conversation Decision notes commonly sit beside rather than within the work Rationale travels as prompt text Recorded decisions remain linked to the tasks they constrain
Recorded execution evidence Output remains tied to one transcript Evidence is added manually as a comment or attachment Results remain local to the harness unless copied External results are recorded against task and graph state
Continuity across people and agents Depends on transferring the right transcript Shares status while deeper context stays elsewhere Depends on each author's prompt reconstruction People and agents read the same durable coordination record
Visible human-review points Review depends on conversation convention Workflow status marks a stop without connected evidence Review must be specified again in each handoff Explicit review records connect evidence to human direction

Operating principles

Control comes from explicit state.

Five principles keep coordination legible without pretending the system replaces human direction.

01 Durable context Project meaning survives the session that produced it.

After an external coding-agent session ends, its execution record stays attached to the task for the next person or agent.

02 Explicit dependencies Readiness follows the graph, not a guess.

When DB-17 completes, API-42 becomes ready because that dependency is recorded.

03 Bounded work A task carries a result, constraints, and a clear edge.

API-42 covers claim idempotency; the downstream MCP client update remains separate work with its own acceptance evidence.

04 Inspectable state Ready, blocked, and review states stay connected to their causes.

API-42 reaches review with the external execution record, changed files, and test result still connected.

05 Human direction People define, review, accept, and redirect the work.

REV-03 presents the recorded result and constraints; a person decides whether to accept it or redirect the next task.

Next action

Give the project one connected record.

Start a workspace for the tasks, dependencies, decisions, notes, and evidence already in motion.

Create a workspace Read the documentation