CLI Agent Agnostic
Vyasa Framework Governed AI Work
Governance that ships with the project
bound by the workflow
acted on by humans and AI.
Sign In
0
MCP Tools
0
CLI Commands
0
API Endpoints
0
Manager UI - First-Class Console
Scroll
Live · 86 MCP tools
One line to
governed AI work.
Give this to your terminal
$
pip install vyasa-vidhi
and let governance take it from there.
Get StartedScroll
How It Works
The Governed Pipeline
Every action flows through the workflow your project defines - propose, guard, score, gate, audit. No shortcuts.
01
The Workflow Binds the Project
$ vyasa init standard --tier standard --git
Workflow: Standard SDLC | Stages: 4 | Gates wired
Workflow: Standard SDLC | Stages: 4 | Gates wired
Pick a built-in SDLC workflow - or build your own. The workflow defines stages, skills, modes, intents, work styles, hooks, and gates. Every contributor - human or AI - binds to it at vyasa init.
02
Work Fractures into Nodes
$ vyasa tree --stage implement
Nodes: 12 | DAG: acyclic | Status: specd → approved
Nodes: 12 | DAG: acyclic | Status: specd → approved
The monolith of "full work" fractures into granular units called nodes. Each node is a bounded step in the project's DAG - small enough for one agent session, connected by depends_on edges, and traceable through the graph.
03
Bounded Session Start
$ vyasa session start --stage implement --skill sce --flow scoring --work-style standard
Session bounded | Flow: scoring | Risk: medium | Scope locked
Session bounded | Flow: scoring | Risk: medium | Scope locked
Eight mandatory fields - skill, mode, stage, target, intent, work style, objective, flow - define who the agent is, how it works, and what it may touch. There are no unbounded sessions.
04
Any Agent Proposes
$ vyasa assistant use
Agent: claude | Intent: implement | Scope: 3 files
Agent: claude | Intent: implement | Scope: 3 files
Claude, OpenAI, or any MCP-compatible agent - frontier or local LLM. The governance contract is identical for every agent: the platform supplies the context, the job, and the tools - not the prompt.
05
Guards & Hooks Validate
✓ Guard: architecture check - PASSED
✓ Hook: pre-apply tests - PASSED
✓ Guard: security scan - PASSED
✓ Hook: pre-apply tests - PASSED
✓ Guard: security scan - PASSED
Deterministic guards and lifecycle hooks inspect every proposal against the workflow's rules - architecture, security, tests - before anything can be applied.
06
Score: Auto + Validator
$ vyasa score feat-auth-01
✓ auto score: 87/100 - governance, drift, tests
$ vyasa score feat-auth-01 --validator opencode
⟳ validator agent dispatched - independent review
✓ auto score: 87/100 - governance, drift, tests
$ vyasa score feat-auth-01 --validator opencode
⟳ validator agent dispatched - independent review
Two independent verdicts. The auto score is a deterministic checklist - completeness, correctness, consistency, governance, drift, test coverage. A second AI validator agent then re-reviews the work in its own workspace. The model proposes; the score decides.
07
Human Gate → Apply & Audit
⟳ Gate: await approval - human required
✓ Approved by: @deepak | 2m 14s
✓ Applied: 3 files | Audit: proof-pack generated
✓ Approved by: @deepak | 2m 14s
✓ Applied: 3 files | Audit: proof-pack generated
Nothing crosses a stage boundary without human approval at the gate. Applied work leaves a complete audit trail - every decision traceable, every session reproducible.
Scroll
Four Surfaces
One Unified Engine
Full parity across every interface. Start in the terminal, monitor in the dashboard, integrate via API.
Terminal First
CLI
Complete developer workflow. Scaffold projects, start bounded sessions, gate approvals - all from the command line.
Read Docs →
Agent Protocol
MCP
86 tools over standard MCP stdio. Connect OpenCode, Cursor, and any MCP-compatible IDE agent.
Read Docs →
Backend Engine
API
FastAPI service driving the session lifecycle, background scoring jobs, and state audits.
Read Docs →
Workflow Console
Manager UI
Visual DAG progression, live interactive terminal, diff review, and gate approvals in real-time.
Read Docs →Scroll
Product
See It In Action
A 71-second guided tour of governed AI work - narration on, volume up.
Scroll
Session Lifecycle
From session start to gate approval - see the complete governed workflow in under 2 minutes.
Scroll
CLI Walkthrough
Terminal-first development with real-time governance, scoring, and validation feedback.
Scroll
Manager UI
Visual DAG progression, live terminal, diff review, and gate approvals - all in one dashboard.
Scroll
The Blueprint
Karpathy saw this coming. Vyasa compiles it.
Across 2025–2026, Andrej Karpathy kept describing a world where models propose, context is engineered, and a score decides. He never built the runtime. We did - it’s called a workflow.
“I like to think of it as: define the context, define the tools, define the feedback loop, define the guardrails - then let agents work.”
Andrej Karpathy - AI Ascent, Sequoia Capital, 2026
“The model does the proposing, but a score does the deciding.”
Andrej Karpathy - Autoresearch, 2025
“Context engineering… the delicate art and science of filling the context window with just the right information for the next step.”
Andrej Karpathy - tweet, June 2025
Every quote is verifiable - karpathy.bearblog.dev · we don’t paraphrase our sources.
Scroll
Idea to Mechanism
| Karpathy’s idea | Vyāsa’s mechanism |
|---|---|
| Define the context | The DAG-filtered manifest: context is computed by walking the project graph around your node - dependencies and dependents only, proportional to the task. |
| Define the tools | 86 MCP tools + 31 CLI commands, wired to the workflow - the agent gets the job and the instruments, not a blank prompt. |
| Define the feedback loop | vyasa score: a deterministic checklist runs instantly; dispatch a validator agent for an independent second opinion. |
| Define the guardrails | Guards, hooks and gates - architecture checks, pre-apply tests, security scans. Fail loud, fail closed. |
| Let agents work | Bounded sessions for any CLI agent - Claude, Codex, Antigravity, OpenCode. Swap agents between nodes; the workflow stays. |
| The small cognitive core | A local LLM with correct context, a pre-defined job and supporting tools can rival frontier models - with zero token-billing dependency. |
| Swarms of specialized models | Work fractures into granular DAG nodes; each node is one bounded session for one specialist agent, orchestrated in parallel. |
Scroll
The workflow is a real graph. Not a metaphor.
Every Vyāsa project is an acyclic directed graph. Work is decomposed into nodes connected by depends_on and cross_refs edges - the same substrate that powers knowledge graphs and code intelligence tools.
When an agent starts a session, Vyāsa doesn’t guess what goes in the context window. It runs a bounded BFS over the graph from the target node and emits a manifest: the node, its dependencies, its dependents. The smallest set of high-signal tokens - computed, not hallucinated.
vyasa tree renders the live DAG. manifest.md is the session’s grounded view. The graph is the context engine - what context engineering was always supposed to mean.
Karpathy’s own tooling sketch assumed the same shape. AgentHub (Mar 2026): “no main branch, no PRs, no merges - just a sprawling DAG of commits going in every direction.” Vyāsa is that DAG - with governance on top.
Scroll
Size Isn’t the Bottleneck
Small model. Right tools. Tight loop. - Vyāsa is that runtime.
00:01
The small cognitive core. True intelligence may fit under a billion parameters. Vyāsa bets on it: right context + right tools > raw model size.
02:00
Specialized model swarms. Programmer, manager, reviewer - in parallel under one orchestration. Granular nodes, per-node agents, one workflow.
07:05
Empowerment, not replacement. With better tools, humans reach further. Vyāsa keeps the human at the gate: AI proposes, humans approve.
13:03
Education as mental fitness. Effortful, rewarding, long-term. The governed loop - propose, score, gate - is that discipline, applied to software.
Scroll
The Fork in the Road
Vibe coding feels fast - until it ships.
Anyone can prompt an agent into building a demo in an afternoon. The question is what happens on week six, when three agents have touched the same module and nobody can say why the auth changed.
Vibe codingprompt → PR → pray
- Context by vibes - the agent hallucinates the codebase, or drowns in a 200k-token dump.
- No unit of work - one prompt sprawls across modules, files, and half-finished ideas.
- Review = hope - a human skims a 3,000-line diff and approves it because it looks plausible.
- Tests optional - “it worked when I ran it” is the quality bar.
- No memory - decisions live in chat scrollback; the next agent starts from zero.
- Agent lock-in - your whole process is tuned to one vendor’s quirks.
- Drift is invisible - until the architecture audit you’ll never run, runs without you.
Governed AI codingpropose → guard → score → gate
- Context by traversal - the DAG-filtered manifest hands the agent its node’s real neighborhood.
- Granular nodes - work fractures into bounded DAG units; one node, one session, one spec.
- Guards & hooks - architecture checks, pre-apply tests, security scans run on every proposal.
- A score decides - deterministic checklist first,
vyasa score --validatoragent second. - Human gate - nothing applies to the project until a person approves the node.
- Full audit trail - every proposal, score and approval is a versioned artifact in the graph.
- Agent agnostic - Claude, Codex, Antigravity, OpenCode. Swap between nodes; the workflow stays.
Scroll
Vibe coding optimizes for the demo.
Governed coding optimizes for the decade.
vyasa session start
agent proposes
guards & hooks
vyasa score
human gate
apply & audit
The 3 a.m. test. With vibe coding, nobody can answer “what changed and why?” without opening the repo. Vyāsa’s manifest and audit trail answer it in one command.
Parallel without chaos. Teams run multiple agents at once because the DAG serializes what must be serial and parallelizes what can be - with gates between.
The local-LLM endgame. A governed loop is the only loop where a small, local model can compete: the platform supplies the context, the job, and the tools - not the prompt. No token billing. No data leaving the machine.
Scroll
FAQ
Questions, answered
What is governed AI work?
Governed AI work means every change an AI assistant makes passes the same loop: propose the work, validate it against the rules, get human approval at a gate, then record it. Nothing lands silently. Vyasa is the framework that enforces that loop.
How do I install Vyasa?
Run pip install vyasa-vidhi, then vyasa --version to confirm. The package is called vyasa-vidhi; the command it installs is vyasa.
How is Vyasa different from agent orchestration frameworks?
Orchestration frameworks run agents. Vyasa governs the work agents produce: sessions with owners, declared pieces of work, machine checks, human gates, review-and-apply, and a timeline of everything. It sits beside your agent, not instead of it.
How do I use Vyasa — CLI, UI, MCP, or API?
One engine, four doors. Use the terminal (vyasa session start), the manager UI (vyasa serve), your coding assistant via the MCP server, or the REST API from scripts and CI. Switch anytime without relearning.
Is Vyasa only for coding?
No. Any work that needs rules and review — documents, plans, content, checklists — can run through sessions, gates, and approvals. Verification checks switch off per project when code rules do not apply.
Is Vyasa available now?
Vyasa is in private alpha. Docs are open for early review; reach support@innosayu.com for access.
Scroll
Ready to Govern
AI Work?
Start orchestrating with the governed AI framework in minutes. Enterprise ready.
In private alpha — contact us for access.
Engine
Node by node. Gate by gate.
That’s Vyasa.
The rock story, frame by frame