Runtime architecture

The intended runtime is a continuous perceive → think → act → reflect loop coordinated through the web API and deployed as an authenticated Stado workload.

Not an operating guide: the commercial and operational hold prohibits live operation. Read exact revisions without attaching real accounts, money, or provider credentials.

System shape

Web coordinator (Next.js + API + Supabase)
        │ pitch · queue · register · heartbeat · service
        └── Stado machine workload
              ├── perception + cognition + execution
              ├── product or worker capability
              ├── memory + accounting + reflection
              └── scoped model-router connection

Perceive, think, act, reflect

1. Perceive: combine balance, burn rate, runway, token performance, recent revenue, and capabilities with market conditions, available work, competitors, news, and resources.
2. Think: select a runway mode, generate candidate actions, and compare expected return, cost, time, risk, and strategic value.
3. Act: execute the best available action through the agent's declared capabilities.
4. Reflect: persist useful outcomes so later cycles can repeat successful strategies and avoid failures.

Entrepreneur and worker separation

Entrepreneurs own a customer-facing product and its revenue. Workers expose a specialized capability to other agents. Buying capabilities instead of duplicating infrastructure preserves independent economics for each service while letting an entrepreneur compose a larger product.

State and external effects

The retained corpus uses state for wallets, tokens, marketplace records, pitches, instances, memory, activity, requests, and costs. The broader source also contains tools for LLMs, cloud, repositories, payments, domains, email, and social systems. Simulated accounting labels are not an isolation boundary for adapters capable of real effects.

Credential boundary

The immutable revenue-agent entrypoint removes ambient model-provider credentials before the process starts and retains only product-scoped Stado credentials. Model-provider credentials belong exclusively in the Stado model router. Stado supplies the workload only STADO_MODEL_ROUTER_URL and STADO_MODEL_ROUTER_TOKEN from the exact wisent-trade-agent-model-router item; the product application never receives the router bearer value.

Prompt instructions, command blocklists, and repository-root checks are not sandboxing. Endpoint allowlists, workload identity, quotas, and revocation must be enforced outside the model, and none supersedes the hold.