Track the work from intent to verified outcome.
KEZEL VIA organizes projects, backlogs, sprints and tasks for software and general project teams, and records how agent-built work was specified, approved, run and checked. Every record is a typed node on the graph kernel, in your deployment's own store, under the organization's SSO, roles and ledger.
One project setting decides how much of this you see.
Each project chooses its mode. A team that does not use agents sees none of the agent machinery, and a hybrid team turns it on for one project at a time.
Traditional
People plan, build, review and ship. Sprints, estimates and assignees work as they always have, for software teams and for general project teams alike.
no agent machinery shown
Hybrid
Some tasks are built by people, some by agents, inside one project. Agent tasks pass a spec gate before they are Ready; tasks for people do not.
spec gate on agent tasks only
AI-native
Agents do most of the building. Estimates leave the interface; the spec, the approvals and the review queue take their place.
estimate fields hidden
When the agent builds, the people own the gates.
Building stops being the bottleneck once an agent does it. What remains to manage is the spec, the approvals, the decisions and the review. Each is a status a person moves, and each move is history.
Specify
A goal and at least one acceptance criterion. The spec is the prompt, so a task is not Ready without one.
Approve
A plan above the project's risk threshold waits for a named approver. Below it, the run starts.
Run
The agent builds. Each run is a record with its cost, its inputs and the task it served.
Decide
When the agent needs a human, it asks. The task waits in that person's queue until the decision is recorded.
Review
A person checks the output against the criteria. Shipped and verified are separate statuses, held by separate people.
an agent is never the accountable party · every stage change is history · a spec edit invalidates a pending approval
Where the work is waiting on a person.
One queue per member: plan approvals, open decisions, output in review and specs still to write, across every project they can see. The agent's questions land here, with the run that raised them.
K·04 · ATTENTION QUEUE · SAMPLE DATA
| VIA-212 | plan approval | waiting · you | risk high · 2h |
| VIA-207 | decision | waiting · you | asked by agent · 40m |
| VIA-198 | review | waiting · you | run 418 · $0.84 |
| VIA-215 | spec | waiting · author | needs criteria |
| VIA-190 | verification | waiting · QA | shipped · 1d |
cost per run is recorded with the run · the flow report reads cycle time by stage from the same history
The team ritual files beside the work.
KEZEL Check-in is the short entry each person posts each period: what moved, what is next, what is in the way. A cadence per team, daily, weekly or monthly, with one entry per member per period enforced by the kernel rather than by habit. Blocked is a flag with a reason. Absence is recorded, so silence and leave are different things. An entry can point at the VIA tasks it describes.
CHECK-IN · PLATFORM TEAM · WEEKLY · 2026-W41 · SAMPLE DATA
| a. menon | filed | moved the queue scorer to run beside the store |
| r. iyer | blocked | waiting on the schema decision, VIA-207 |
| s. khan | absent | leave |
| t. george | open | not yet filed · 3h left in period |
3 of 4 reported · 1 blocked · comments stay on the entry as a record
- the recurring ritual: entries, blockers, absence
- KEZEL Check-in
- sprint figures: planned, completed, carry-forward, burndown
- VIA
- dashboards assembled over either
- analytics module, K·03
One implementation of each figure. Check-in reads VIA's sprint numbers and computes none of its own.
The work record is data, and it is treated like the rest of yours.
A hosted tracker holds the spec, the decision log and the run history outside your boundary. In VIA those are typed records on the graph kernel, with the same roles, history and ledger as every other component. The two columns below are one shipped state and one labelled roadmap.
Graph kernel, in your deployment's store
The kernel governs the schema in the deployment's own database. Every VIA and Check-in record is a typed node there, scoped to the organization, read and written under its roles.
- projects, folders, epics, sprints
- tasks, subtasks, dependencies
- specs, approvals, decisions
- agent runs, cost, provenance
- check-in entries and comments
Graph kernel, in the execution plane
The kernel moves beside the Streaming Agent, so VIA runs the way the orchestration engine already does: dispatched into the boundary, written to the in-boundary ledger. The records do not change shape; the place they are served from does.
Labelled roadmap because it is one. The kernel was made store-dependent for this move, and nothing on this page describes it as shipped.
SSO and roles · the organization's KEZEL IAM, no separate accounts · guests scoped and sponsored · every important change kept as history
Bring a real workload. We’ll answer it in place.
Start with a demo on our sample boundary. Move to a pilot in yours once your security review clears it.