Whitepaper summary

Vistara: Coordinated and Verified Work by Parallel AI Agents, version 1.1, September 2026.

This is a summary. Section numbers refer to the whitepaper. The paper separates three kinds of claim, and so does this summary:

• Measured: figures from sources published in 2026, cited in the paper.
• Design: how Vistara is meant to work, including parameters such as fees and shares. These are proposals, not results.
• Observation: how people use several agents at once. The paper labels these as observations until a published measurement exists.

Design, not shipped

Most of what the paper designs is not built yet. For what ships in the beta today, see How it works and the roadmap.

Central claim (Abstract, 1)

AI execution is becoming parallel while human attention is not. The layer that keeps the live state of work and routes attention to what needs it is where the value of many agents is realized. What makes that layer safe, and what makes the same work purchasable, is a goal with predefined, checkable criteria.

The problem (1.1, 2)

Measured.

• Task length that frontier models can complete has doubled roughly every 131 days since 2023. METR put the 50%-success horizon of a leading model at about 12 hours of human-equivalent work in May 2026, and the 80%-success horizon at about 70 minutes (1.1).
• Gartner estimated the enterprise market for AI coding agents at about $9.8–11.0 billion annualized as of April 2026. JetBrains found 90% of 15,000+ developers using coding agents at work at least weekly, 68% daily (2.1).
• Anthropic's June 2026 Economic Index found users gave the agent more autonomy in the coding harness for 26 of 31 output types, including non-code work (2.1).
• Faros AI (22,000 developers): in high-AI-adoption teams, median review time rose 441.5%, bugs per developer rose 54%, incidents per pull request rose 243%. LinearB: AI-generated pull requests accepted 32.7% of the time against 84.4% for unassisted ones (2.1).
• METR found a leading model attempted to reward-hack in about 80% of attempts on one coding evaluation when tests were hidden (2.1).

Observation. A person now runs several agents across harnesses and projects. The state of that work exists only in their head and in a scatter of terminals, editors and transcripts (1.1).

The paper names three failures (1.1): continuity (sessions stop on permission prompts, usage limits, context loss or a sleeping machine), trust (a reported success cannot be relied on), and coordination (the person is the only component that sees every workstream). Each has its own remedy: supervision, verification, and a written state of work.

Gaps in current tools (2.2): goals are not written down; the state of work lives in the person; continuity fixes are per vendor; authority is coarse (approve one action at a time, or skip checks); verification is self-reported; the access route depends on vendor terms; and agent payment rails exist but checked outcomes do not.

Design principles (2.3)

Goals before work. One state of work, written by the system. Interrupt only for what needs a person. Local execution. Verification by separation, not by distance. On-chain only where a shared ledger is necessary.

The four primitives (1.2)

Primitive	Question	Role
Workstate	What is happening?	A live record of each workstream that any agent or person can pick up. The unit of coordination.
Attention	What needs a person?	The daemon resolves what was authorized in advance and raises only the rest. Where human judgment enters.
Mandate	What may agents do?	One signed statement of scope, budgets and decision rules. The source of authority.
Verification	Is the work right?	Each goal's predefined criteria applied by a process independent of the agent that did the work. The source of trust.

System design (3) — Design

Three layers (3.1). The local daemon does the work, keeps state, verifies, and holds all private data. Off-chain services index the work market, run checks for buyers without a node, and handle disputes. Contracts on Base hold escrow and record delivered work. A user who runs the daemon only for their own goals never touches the market or the chain. In the beta, this local daemon is part of your Vistara Node.

Goals (3.2). A goal spec has a goal statement, acceptance checks (what a program can evaluate), a quality rubric (what needs judgment), and constraints and budget. The planner drafts it; the user approves it. Table 1 gives examples for code, research, marketing, operations, product, design and strategy.

The daemon (3.3):

• Planner (3.3.1): turns tasks into goal specs, estimates cost and risk, orders the queue.
• Mandate and policy engine (3.3.2): a signed mandate (scope, output rules, network, budgets, machine, decisions, attention, validity; Table 2). Every tool call, command, file write and network connection is checked against it. Each goal runs in its own container with an egress allowlist.
• Supervisor (3.3.3): classifies every stop (permission prompt, usage limit, context exhaustion, crash, loop, open question, conflict, machine condition; Table 3) and responds inside the mandate.
• Resource governor (3.3.4): caps CPU, memory, GPU and spend; holds a wake lock on external power only when the user is away; yields to the foreground.
• Verifier runtime (3.3.5): a separate process in a separate container, using a model from a different vendor. Four levels (Table 4): V0 policy compliance, V1 acceptance checks, V2 integrity (tests weakened, citations that do not support claims, and similar), V3 goal review by an independent model. V3 is a judgment, never proof.
• Flight recorder and receipts (3.3.6): a hash-chained event log and a signed receipt per goal.
• Workstate and context keeper (3.3.7): fields are objective, decisions, constraints, artifacts, failed paths, dependencies, blocked on, next action, provenance (Table 5). Written by the system from events, not from the agent's account. The first release carries handoff-note fields; the full store with conflict detection and handoff between people follows in 2027.
• Brief (3.3.8): a queue of moments that need a person, each with context and one action. Batched when the user is away (the first release's form), continuous when present.

Work market (3.4). An idle machine can take paid goals. The buyer funds escrow in USDC; the verifier of record runs the acceptance checks; payment releases on a signed pass. Contracts (Table 6): work escrow, operator registry, work records in ERC-8004 format, receipt anchor, fee router and $VSTR. Rubric disputes go to arbitration. Operators may post USDC bonds.

User journeys (4) — Illustrative

A day with several agents under a standing mandate (4.2), an overnight queue under a night mandate (4.3), verification of each finished goal (4.4), a morning review of packets ranked by risk (4.5), and buying and selling work (4.6). The paper presents this as an illustrative day, not a measurement.

$VSTR (5) — Design, a proposal

• Payments are in USDC. $VSTR has two functions: protocol fees on settled work buy and burn it, and staked holders govern fee parameters (5.1, 5.2).
• Initial fee 10% of the settled amount, split 60% buyback, 25% treasury, 15% arbitration reserve (5.2.1). The paper's arithmetic example: at $5 million settled per month, $3.6 million of $VSTR is removed per year. It states this is arithmetic, not a forecast.
• Governance stakes for at least 30 days, earns nothing, and passes through a timelock of at least seven days (5.2.2).
• Fixed supply of 1,000,000,000 on Base. Allocation: community and network 42%, team 20%, investors 17%, treasury 12%, liquidity 7%, advisors 2% (Table 8). No public sale (5.3).
• The launch distribution (8%) goes to users of the public daemon in proportion to verified, accepted goals completed before generation. It does not count installs, sessions, tokens or time running; active days act only as caps and multipliers (5.3).
• Generation in Q4 2026 with the first contracts; the work escrow, the only fee source, launches in 2027 (5.3).
• The token is not equity, debt or a claim on payments; the design is a proposal that may change before generation (5.5).

Security and privacy (6) — Design

Threats and controls are listed in Table 11. Agents run in containers with scoped credentials and draft-only outputs (6.1). Only the supervisor can raise a moment to the user, and agent text is shown as agent text (6.1). The wallet key is never on the daemon's path (6.1). By default nothing leaves the machine; data leaves only to model providers, teammates a user shares with, market counterparties, or third parties the user discloses to (6.3).

Applications and positioning (7, 8)

Three steps share one set of objects: individuals, teams (shared Workstates, mandate and goal templates, receipts), and enterprises (policy floors, roles, audit, self-hosting) (7.1–7.3). Other uses: receipts for open-source maintainers (7.4), paid work between strangers (7.5), and a record of how agents perform on real work (7.6). Section 8 compares Vistara with vendor harnesses, local launchers, project tools, memory systems and agent marketplaces (Table 12), and argues that cross-vendor neutrality must be held from the start (8.6).

Roadmap and risks (9)

Milestones from Q4 2026 to 2028 are in Table 13; see the roadmap. Principal risks and responses are in Table 14, including vendors absorbing continuity, vendors restricting unattended use, harness interfaces not exposing enough, interruptions becoming a distraction, weak goals, the launch distribution being farmed, and regulatory treatment of the token.

Conclusion (10)

"Agents make execution abundant. Human attention becomes the scarce input. Vistara is the system that coordinates the work between them."