AI development with full traceability: from idea to line of code
Work Graph links business goals, architecture and code into one graph. Every task has a contract, every change has proof.
Three layers of one development cycle
For the agent this is not chat history — it is a live work map: what is open, what is linked, what is already proven.
Intent graph
Every task starts with a review: which problem we solve, which options exist, what the boundaries are. Links between tasks stay visible.
Execution graph
Tasks move from plan to outcome. The agent works against a contract: clear inputs and outputs, allowed actions, required proof.
Memory graph
Closed tasks with checks become project memory. Links to files and decisions stay in git — the next session opens the same map.
How to install Work Graph
Install into an existing repository: local backlog, operator UI, and MCP for your agent. Requires Node.js 20+ and npm.
For agents:
Install Work Graph in this project https://www.npmjs.com/package/@work-graph/cli and open the local UI.
In your project directory, run:
cd /path/to/your-project
npx @work-graph/cli init .
npm install
npm run workgraph:ui
Then open:
http://localhost:4177/
init writes .work-graph/config.json, intent/, npm scripts, and optional IDE files (for example .cursor/mcp.json with npx -y @work-graph/mcp and WORKGRAPH_ROOT). Existing intent/index.bvc and architecture/main.bvc are preserved. Reload MCP in your IDE after npm install.
Verify: npm run workgraph:doctor
How to get started with Work Graph
-
Install in 2 minutes Run npx @work-graph/cli init in your project. You get a local board, backlog and MCP for Cursor or another client.
-
Describe the task in chat Ask your AI agent to run a review or create a work item. Work Graph links it to your architecture automatically.
-
Get results with proof The agent works against the contract. You see statuses, checks and readiness proof on the board.
What Work Graph looks like
Local Work Graph UI: from reviews and tasks to board, verification and memory — one work map in the repo, not chat archaeology.
Analytics links decisions to delivery work
AN records capture reasoning, options and boundaries before work enters the backlog. Lineage, epic links and implementation ties stay in the intent graph inside git — not in a separate doc or chat summary.
A task is a machine-readable BVC contract
Instead of parsing a long thread — one task contract in one place. The agent knows which files, commands and checks are required before done.
The board shows how work is moving
Columns from backlog through ready, doing and done with BVC work items and owners. Status follows contract and evidence — not an arbitrary label someone typed in a thread.
Verification decides when a task can close
Tier A/B/C matrix: deterministic commands, optional checks and environment gates. assert_task_ready_for_done returns violations[] — a contract verdict, not agent prose.
Project memory keeps verified outcomes
Closed tasks with checks become project memory. The next session reads git, not a recap of the previous chat.
Architecture orients you in a large repo
Blocks from architecture/main.bvc and derived projections map domains and containers without breaking away from the intent graph and backlog you execute against.
Contract loop: intent → execution → memory
Connect strategy to execution: from AN review to verified memory in git — in one local work graph.
Three layers of one development cycle
One product map — three layers: why you are building, how work moves, and what you have already proven and remembered.
Evidence ledger
A task is not done because the agent said so. It is done when the contract has verifiable proof — like a checkpoint marked on the map.
Agent-readable documentation
Every critical page has markdown, examples and machine-readable discovery so Cursor, Claude Code and MCP clients can use the site as a tool.
Why a plain AI workflow is not enough
Chat stores conversation. Work Graph stores work: a contract per task, backlog state and proof — so every session reads the product map instead of reconstructing meaning from tokens.
A task is readable by humans, git and agents
BVC describes intent, projection defines execution and evidence turns the result into memory.
#ImplementTraceLinksV1@en<[
Basis:
Current step tracing is not validated in CI
There is no work.id ↔ files ↔ tests linkage
Vector:
Implement trace validator
Add MCP tool get_unified_linkage
Goal:
Any task with trace.* labels has automatic integrity checks
Labels:
profile: work_item
tier: A
trace.codegen: false
Checks:
npm run test:deterministic
bvc lint intent/**/implement-trace-links-v1.work.bvc
]>claim_work_item("implement-trace-links-v1")
→ get_work_contract(work_id)
→ edit target_files
→ run allowed commands
→ validate_evidence(structured_json)
→ assert_task_ready_for_done(work_id)
→ add_work_item_evidence + completeWhy a plain AI workflow is not enough
Plain AI workflow
Intent stays in heads or chat
Done = agent words
Work Graph
Intent is formalized in the graph — a product map
Done = proof + verified gate
Jira / Linear
Tasks and statuses in the cloud
Contract and proof live outside the repo
CI / tests
Checks commands
Does not know why the task existed
Who Work Graph is for
For tech leads and architects
See the full picture: from review to final code. Decisions, contracts and proof stay in git, not in chat summaries. Example: in 5 minutes, find which task and review led to a given commit.
For developers
One backlog and a clear contract before you start. Explicit file boundaries and board states — less improvisation, more predictability.
For AI agents
Do not squeeze meaning from a long thread — read the task route and current position on the map. Execute the contract instead of saying done in prose.
FAQ
Is Work Graph a task tracker?
No — it is a layer on top of your process. WG adds traceability and contracts to what you already use: Cursor, Claude Code, git. You still get a board and statuses, but the unit of work is a provable task, not a chat ticket.
Does Work Graph replace Cursor or Claude Code?
No. Keep your IDE and agent. Work Graph adds a work map, contract control and audit — a layer above execution, not a replacement.
Where is the data stored?
Locally in your repository. No Work Graph cloud, no external servers for the canon. You own the work map.
What is BVC?
Basis · Vector · Goal. BVC describes an intent atom: context and reason, concrete action and success criterion. It is readable by humans, validated by schema and precise enough for LLM agents.
How does an agent communicate with Work Graph?
Through MCP. The IDE config points to @work-graph/mcp, then the agent calls tools like get_work_contract, submit_evidence or assert_task_ready_for_done. WG returns structured data, not chat prose.
Does Work Graph work offline?
Yes. The Work Graph core works locally. Network access is only needed for your model provider or IDE agent; WG itself does not require external services.
Is Work Graph useful without AI agents?
Yes. A structured backlog, links to architecture and decision history in git help even without an agent. With an agent you also get automatic proof collection and readiness checks.
How is WG related to CI/CD?
WG does not replace pipelines. It requires their results as evidence. A task can demand npm run test:login; the agent runs it, submits exit code and output, then WG checks the evidence before done.
Does WG support 1C / OneBase?
Yes, as a domain vertical through specialized MCP servers and evidence contracts. Domain-specific metadata or checks can become evidence in the same contract layer.
How do I know the agent did not hallucinate task completion?
Through the Evidence layer. The agent must call add_work_item_evidence with command output, exit code and artifact hashes. Work Graph validates the result against the task contract.
What happens if the agent violates the contract?
WG acts as a gate. If required Tier A evidence is missing, runtime returns PolicyViolation, the task stays open and the violation is written to the audit log.
For LLMs and integrations: /faq.json