Execution architecture¶

English | 日本語

Proportionate improvement and outcome evidence¶

Routine fixes reuse the existing bootstrap and delivery gates without another plan, observation artifact or approval. The optional work-route projection makes that decision reproducible and retains the safe route when evidence is unknown. See the entry contract.

For new material outcome plans, use v2 with an accountable owner, finite decision window, success and failure criteria, and one action for unavailable evidence. Existing v1 plans retain their recorded contract until explicitly revised; validation does not schedule observation. The observation owner describes authoring and compatibility.

Keep improvement dispositions in the authoritative Work Item. Deferral requires a revisit event. A passing reproduction can support mechanical prevention while operational recurrence and product outcomes remain pending or unavailable; no eligible events is not evidence of success. The learning owner defines the three evidence classes and optional validation. No new backlog, background observer or publication authority is introduced.

Current interaction sequence¶

This view answers one question: who acts in what order from an interactive request or optional Control wake-up through accepted delivery evidence?

sequenceDiagram
    actor Human
    participant Control as Optional Control
    participant Codex
    participant AIT as AI Teams
    participant GitHub
    participant Provider as Selected provider

    alt Interactive request
        Human->>Codex: Request work and supply authority
    else Trusted orchestrated wake-up
        Control->>Codex: Start isolated work
    end
    Codex->>AIT: Run the coordination contract
    AIT->>AIT: Establish Goal, constraints, profile, and Bet
    opt Bounded independent challenge is justified
        AIT->>Provider: Request one authorized review primitive
        Provider-->>AIT: Return bounded evidence
    end
    AIT->>GitHub: Record Work Item and delivery objects
    AIT->>Codex: Implement and run focused checks
    Codex->>GitHub: Publish exact-head candidate
    GitHub-->>AIT: Return validation and merge evidence
    AIT-->>Human: Report delivery readback, outcome evidence, and Next Bet

The coordinator makes product and authority decisions. Codex/native tools edit and test the workspace. A connected provider performs only the primitive for which it is selected and authorized. AI Teams does not transfer provider credentials or silently substitute another system of record.

Adaptive execution topology¶

AI Teams chooses topology after it understands the task; agent count is not a product goal. It compares the total coordination cost with the expected quality, elapsed-time, and independence benefit. One accountable coordinator with no specialists is the default because it avoids handoffs and duplicated context. Deterministic tools handle mechanical facts before model work is added.

Specialization is justified only when bounded independent expertise, context isolation, parallel work, or challenge materially improves the result. The coordinator keeps the Goal, authority, integration, and acceptance decisions, and every specialist returns bounded evidence to that coordinator. These limits reject both "more agents means more quality" and "one agent forever": the simplest sufficient topology wins for the current task, and it may change when measured cost or outcome evidence changes.

The normative budgets and delegation limits remain in the execution-economics contract.

Provider resolution¶

For operations in the accepted capability inventory, selection proceeds through host/platform native, installed Plugin, connected Connector or MCP, standard CLI/service, then bundled fallback. Each provider class is observed at most once for one operation. Unknown or unauthorized capability fails to a bounded handoff.

The machine-readable inventory is the source for the generated capability reference. Detailed semantics remain in the provider-resolution contract.

An internal integration can opt into a namespaced external manifest and an exact-scope allowlist without editing core coverage. Write selection additionally requires a reviewed conformance report bound to the manifest and observed implementation digest. The integration owns its actual calls, credentials, timeouts and receipts; selection runs no external code. See the external provider guide for typed contracts, approval, failure cases and rollback.

Optional external Control¶

The bounded Control MCP client can connect to independently distributed Qoo257/ai-teams-control. External Control owns Issue discovery, scheduling, durable execution- coordination queue and recovery state, worker lifecycle, and optional provider-event integrations. This Plugin owns no scheduler, queue, poller, or orchestration runtime. Rebuildable local caches and configured reflection artifacts retain their declared local owners. GitHub Issues and pull requests remain authoritative for GitHub delivery, and external Control cannot weaken repository acceptance or trust boundaries.