Agentic income

Agentic Income

Agentic Income turns a repeated professional workflow into a governed, sellable service.

The agent is an operator. The human or legal entity remains the principal, supplier, account owner, payee, and responsible party.

Invocation

Use:

/agentic-income MODE GOAL

Modes:

• discover — rank opportunities by buyer pain, access, evidence, risk, time to cash, repeatability, and support burden.
• validate — define buyer evidence, fixed scope, price test, acceptance criteria, costs, and kill criteria.
• build — create the manifest, app, workflows, connectors, authority policy, evals, and runbooks.
• sell — create a demo, landing page, proposal, and reviewed outreach assets.
• deliver — deploy into customer-owned accounts and run acceptance tests.
• operate — monitor service level, cost, exceptions, incidents, renewals, and margin.
• publish — expose a safe Skill, MCP tool, A2A Agent Card, or metered endpoint.
• prove — reconcile paid and accepted work, costs, human effort, quality, incidents, and evidence.
• improve — turn production traces, failures, and feedback into evals and reviewed changes.

If MODE is omitted, infer it from the request and state the inferred mode.

Outcome Pack contract

Every build must produce or update:

• income-system.json;
• offer and buyer contract;
• input and output schemas;
• app and agent behavior;
• skill and protocol interfaces;
• connector inventory;
• deny-by-default authority policy;
• deterministic, model, and human evals;
• support, incident, rollback, and revocation runbooks;
• economics and proof records.

Validate against schemas/income-system.v1.schema.json.

Opportunity ranking

Prefer:

1. A painful workflow with existing budget and a short path to acceptance.
2. A narrow buyer and repeatable input/output contract.
3. Customer-owned systems and credentials.
4. Fixed scope and transparent pricing.
5. Deterministic acceptance, low support, and reusable implementation.
6. Recurring assurance earned through monitoring, evals, and updates.

Reject:

• vague “AI transformation” without a buyer or accepted outcome;
• regulated decisions in medical, employment, credit, insurance, or legal advice;
• unrestricted wallet, bank, email, or production authority;
• arbitrary bespoke integrations;
• autonomous cold outreach;
• revenue guarantees, custody, pooled payouts, or performance fees without clean attribution;
• generic agent marketplace before verified supply and demand exist.

Authority model

Bind every service to:

Legal principal → agent identity → capability → scoped credential → policy → auditable action.

Agents may research, classify, draft, schedule, update approved records, run tests, and propose reversible changes.

Human approval is mandatory for:

• prices and binding quotes;
• contracts and legal terms;
• person-directed broadcasts;
• refunds outside policy;
• production credentials or wider permissions;
• bank or wallet transfers;
• budget increases;
• destructive or irreversible actions;
• public income claims.

An operational email is not legal identity. A delegated wallet signer is not wallet ownership. Wallet keys, bank credentials, and seed phrases never enter model context.

Build loop

1. Observe the buyer workflow and collect payment evidence.
2. Score opportunity, risk, repeatability, and support.
3. Propose one Outcome Pack.
4. Validate offer, acceptance, budget, authority, and stop conditions.
5. Build in a branch or sandbox.
6. Verify routine, authority, security, recovery, cost, and latency evals.
7. Deploy into customer-owned accounts.
8. Reconcile accepted outcomes, money, costs, incidents, and owner time.
9. Improve or retire from evidence.

Proof contract

Never use invoice screenshots as proof.

Record:

• quoted, authorized, invoiced, paid, earned, refunded, and adjusted events;
• customer acceptance;
• system and eval versions;
• direct platform, model, tool, support, and owner-time costs;
• completion, exception, and incident rates;
• evidence level: reported, document-reviewed, connector-observed, or independently attested.

Public claims require consent and human approval.

First reference system

Use examples/request-to-quote-desk as the beachhead.

It is for renovation, commercial maintenance, specialist installation, and B2B technical services. It qualifies inbound requests, asks for missing information, schedules estimates, drafts non-binding quotes, updates the CRM, and routes commercial commitments to a human.

The recommended validation model is a fixed deployment plus recurring managed assurance. Do not charge a performance fee initially.

Protocol posture

• Agent Skills carry operating knowledge.
• MCP connects tools and data.
• A2A exposes remote task services and signed Agent Cards.
• AP2 can represent payment authority.
• UCP and ACP can support commerce discovery and checkout.
• x402 can meter capped machine endpoints.

Compose these protocols. Do not fork them or create a new agent framework.

The innovation is the service and proof contract binding principal, outcome, authority, system version, evaluation, economics, and evidence.