v1.4.0 GitHub ↗

Role-first governance for AI agents

Role-first organizing principle

An autonomous organization runtime for AI agents.

ANS Studio organizes multiple AI agents into a team with roles, boundaries, dispatch, and independent acceptance—not a single assistant working alone.

The organizing principle is Role-first: define business responsibility and roles before modules and code ownership. Write authority comes only from role boundaries. Claude is the default engine; Pi and Codex are also available. The CLI supports demo, Pi, Codex, and Claude.

Download v1.4.0 View source on GitHub ↗

macOS 13+ / Windows 10/11 MIT License Native builds for three platforms

ANS Studio desktop app screenshot: graphite theme, five-role navigation on the left, and an intent confirmation card in the main area.
Real desktop app (Chinese UI): graphite theme, five-role navigation, and an intent confirmation card.

A smarter assistant is not the same as an organization that can take responsibility.

A model can write code, but it does not know who should own the result. Role-first puts the organization before the code: roles before modules, boundaries before writes, evidence before acceptance.

  • Responsibility before modules

    Define business responsibility and roles first, then modules and code ownership; the role card states duties, and Section 1 of boundary.yaml lists the paths a role may change.

  • Boundaries are part of the runtime

    Write authority comes only from role boundaries. Out-of-bound writes are rejected before side effects and pointed back to the correct owner. Shell commands go through the approval chain like everything else.

  • Acceptance is an independent role, not a self-declaration

    A report saying “done” is only a statement; Proof independently checks delivery and hand-back evidence before issuing an acceptance card.

Three powers · five roles

Role-first lands as five built-in governance roles in new or empty projects. The three powers are proposal, team formation, and orchestration; communication and acceptance are not decision powers. None of the five holds final approval.

  • Lead

    liaison Default entry

    Customer communication and the default entry point; writes intent to docs/intents/; also acts as workflow manager.

    PowerCustomer communication · Workflow management

  • Draft

    rapporteur

    Forms proposals and cross-role contracts.

    PowerProposal

  • Crew

    nominator

    Nominates project roles and writes role cards and boundaries.

    PowerTeam formation

  • Steward

    convener

    Orchestrates the flow and dispatches tasks.

    PowerOrchestration

  • Proof

    verifier

    Independently checks evidence and issues acceptance cards.

    PowerAcceptance

None of the five holds final approval; final approval stays with you. Built-in roles ship with the app and have no role directories; their file writes are limited to governance files and evidence, and they do not implement or test.

From intent to acceptance, a checkable process

An autonomous organization runs on process: each formal task moves in a fixed order, and every output lands in files or the ledger, ready to review and verify.

  1. 01

    Intent confirmation Lead

    State goals, scope, and acceptance criteria to Lead; the intent is written to docs/intents/, and only passes to Draft after confirmation.

  2. 02

    Proposal and contracts Draft

    Draft forms a proposal and cross-role contracts from the intent; you choose accept, accept-quick, revise, or reject.

  3. 03

    Team formation and appointment Crew

    Nominates project roles and writes role cards and boundaries; appointments and each path write pass through confirmation.

  4. 04

    Flow and dispatch Steward

    Writes the flow record, orchestrates the flow, and dispatches formal tasks to project roles; tasks queue while a role is busy.

  5. 05

    Implementation and hand-back Project roles

    Project roles implement and test within their own boundaries, then hand back reports and evidence.

  6. 06

    Independent acceptance Proof

    Independently checks delivery and hand-back evidence and issues an acceptance card; you decide accept or reject.

Boundaries are gates, not prompts

Role-first does not rely on the model's good behavior: writes, shell, and automatic judgment each have a gate on the execution path.

  • Write gate

    Role cards, boundaries, proposals, flows, acceptance, and file writes get a preview or confirmation card before writing; out-of-bound writes are rejected and pointed back to the correct owner.

    write_file 角色卡/提案/… → rejected · owner: Draft / proposal

    The example keeps the real repository path; role directories in this project are named in Chinese.

  • shell approval

    Every role has shell capability, and all of it goes through approval; a read-only allowlist runs directly; risky, review, and deny each require approval from you or the judge agent.

    rm -rf build/ → approval card · runs only if approved

  • judge agent

    Read-only and fail-closed. Insufficient budget, insufficient evidence, unclear risk, or a missing intent all block automatic approval. A successful auto-approval is labeled “judge-approved” and never impersonates your click.

    Auto-approve: on → judge-approved

Honest caveat: shell has no OS sandbox; file side effects of an approved command are not covered by the write gate; the approval chain is the only control. Open only projects you trust. See README current limitations.

Three engines, one governance chain

Engines are the execution layer: switching engines does not switch the organization; role boundaries and gates stay on the same governance chain. Each engine uses its own configuration and never falls back to another engine when configuration is missing.

Claude Default

Required
ANTHROPIC_API_KEY
Optional
ANS_CLAUDE_MODEL, ANTHROPIC_BASE_URL

Pi

Required
ANTHROPIC_AUTH_TOKEN, ANS_PI_BASE_URL, ANS_PI_MODEL

Codex

Required
CODEX_API_KEY or OPENAI_API_KEY, ANS_CODEX_MODEL
Note
Custom endpoints must be compatible with the Responses API.

Engine configuration in the README

Download v1.4.0

Released 2026-10-20. The app bundle includes its own runtime, so launching the app needs no separate Node.js install; running project commands still requires the project's own development toolchain.

More release materials Release notes release-provenance.json overlay.patch SHA256SUMS-overlay.txt

Not signed or notarized: macOS Gatekeeper or Windows SmartScreen may warn that the source is unverified. Download from the GitHub Release and verify SHA256 before running.

From a paper to a runnable governance system

ANS Skill is a role-first AI development skill inspired by the Role-First Software Governance (RFSG) paper; ANS is a name, not an acronym. Role-first comes from this paper, and ANS Studio turns it into a runnable desktop app and CLI: role cards, boundaries, and gates are implementations of its principles.

Wang, Zhongren. 2026. Role-First Software Governance: Asymmetric Authority Boundaries for AI-Native Agent Systems. DOI: 10.5281/zenodo.22824700

Read the paper ↗