Content
# YourAIWebtop — Powered by AgentForge Protocol
YourAIWebtop is building the next desktop for the AI era — a cloud-native workspace where AI agents, workflows, messaging channels, enterprise knowledge, and APIs work together to automate real business operations. Powered by AgentForge Protocol, it enables individuals, businesses, creators, and enterprises to build, deploy, govern, and monetize AI agents from a single platform.
**YourAIWebtop** ([https://youraiwebtop.com](https://youraiwebtop.com)) is an AI web desktop
for agents, workflows, channels, and business operations. The underlying
technical infrastructure is the **AgentForge Protocol** — a common backend and
runtime that lets a business create, deploy, govern, and monetize AI agents, then
expose that same agent infrastructure to its own customers and developers under
one protocol. It has two halves that share one backend and one runtime:
- **AgentForge Protocol** — a public HTTP API (`/v1/*`) for creating, running,
evaluating, and monetizing agents from outside the web app: scripts, CI
jobs, other backends, and enterprise systems integrating AgentForge as
their agent layer.
- **YourAIWebtop** — the web SaaS built on top of the Protocol: **Desktop**
(`/app/desktop`) — the daily operating environment where humans and AI
Employees collaborate, organized into user-defined **Boards** (Marketing,
Sales, Finance, Support, …) of draggable/resizable widgets (AI Employee,
Chat, Tasks, Kanban, Knowledge, Analytics, Whiteboard, and more) — a
**Marketplace** — the distribution layer for discovering and installing AI
Employees into Desktop — a creator/business portal for publishing agents
and tracking revenue, a billing/subscription/usage layer (Stripe, Wise
Payments, or sandbox), an admin/operator portal, channel delivery through
the **OpenClaw gateway** (Telegram/Slack/WhatsApp and other messaging
channels behind one integration), a **Protocol Data Layer** that records
every protocol-level event (runs, tool calls, channel sends, approvals,
support tickets, subscriptions, workflows) into typed ledgers for
usage/revenue/quality reporting, and an **Agent Operations Console**
(`/app/operations`) — the engineering and operational control center
powering every AI Employee: tasks, long-horizon goals, multimodal runs,
traces, benchmarks, datasets, scheduler, and GPU workers. Every Operations
page links back to the Desktop Board that owns the selected AI Employee.
Status: Private Beta | Python 3.12 | FastAPI | React | Proprietary
## Product & Business Model
YourAIWebtop's business model is a multi-sided agent platform with five
distinct user groups, all sharing one runtime, one billing/usage layer, and
one event-sourced Protocol Data Layer:
1. **Users / B2C** — people who browse `/marketplace`, subscribe to paid
agents, and run them through the web UI. They evaluate agents by
`value_score` (rating, usage, success rate, benchmark score, knowledge
completeness, transaction volume) before subscribing.
2. **Creators / businesses** — build agents (instructions/system prompt,
category, knowledge base, enabled tools, channel connections, and a
pricing model — free, subscription, or per-run) at `/app/agents`, publish
them to the marketplace, connect them to messaging channels via the
OpenClaw gateway, and track revenue at `/app/creator/revenue`. This is
the same persona as a business running AgentForge as its customer-facing
agent layer, not only an individual hobbyist publisher.
3. **Developers / API users** — integrate marketplace agents (or their own
business's agents) into external products via the Protocol API
(`/v1/*`) using a developer API key managed at `/app/developer`, instead
of a logged-in user session.
4. **Enterprises** — adopt AgentForge Protocol as their AI agent
infrastructure strategy: the `enterprise` plan (unlimited quotas, see
[Billing & Monetization](#billing--monetization)), BYOK model routing so
an enterprise's own model credentials are used instead of pooled platform
keys, and the Protocol Data Layer's usage/revenue/quality ledgers as the
audit trail an enterprise procurement process expects.
5. **Admin / operators** — run the platform itself: the admin portal
(`/admin`, `/admin/revenue`) for platform-wide revenue, pricing controls
(`PricingSettings`), and the Agent Operations Console for watching
task/benchmark/scheduler health across every tenant's traffic.
AgentForge takes a platform cut of paid usage (currently a 70% creator / 30%
platform split, see [Billing](#billing--monetization)) on top of the revenue
lines below. Every agent run — whether triggered from the marketplace UI, a
channel message via OpenClaw, or the Protocol API — flows through the same
runtime/evaluation/trajectory layer described below and is recorded in the
Protocol Data Layer, so usage, quality, and revenue metrics stay consistent
across every surface and persona.
### Revenue lines
| Line | What it bills | Where it's modeled |
| --- | --- | --- |
| Platform subscriptions | Flat monthly plans (`free`/`pro`/`creator`/`enterprise`) gating quotas and marketplace features | `Subscription` table, [docs/MONETIZATION.md](docs/MONETIZATION.md) |
| Creator/business subscriptions | A creator/business's `monthly_price` on a published agent, split creator/platform | `AgentSubscription` + `Transaction`, [docs/MONETIZATION.md](docs/MONETIZATION.md) |
| Marketplace subscriptions | The same `AgentSubscription` mechanism viewed from the consumer side — a `/marketplace` user subscribing to a discovered agent, recorded in `revenue_ledger`/`Transaction` and surfaced on `/app/billing` | `revenue_ledger`, [docs/MARKETPLACE.md](docs/MARKETPLACE.md) |
| API usage | Developer calls to `/v1/*` with an API key, metered by `api_price_per_1000_calls` | `protocol_usage_ledger`, [docs/API_PROTOCOL.md](docs/API_PROTOCOL.md) |
| Model usage markup | Platform markup on top of estimated model provider cost for platform-key runs (`model_markup_percent`, default 15%) | `UsageLedgerEntry.platform_markup`, [docs/MONETIZATION.md](docs/MONETIZATION.md) |
| Channel usage | OpenClaw-routed channel sends (Telegram/Slack/WhatsApp/etc.), billed at a premium unit multiplier | `channel_events`, `app/tools/executor.py` `PREMIUM_UNITS`, [docs/OPENCLAW_INTEGRATION.md](docs/OPENCLAW_INTEGRATION.md) |
| Workflow usage | Multi-step planner workflow executions tracked independently of single agent runs | `workflow_events`, [docs/OPERATIONS_PLANNER.md](docs/OPERATIONS_PLANNER.md) |
| GPU / premium jobs | GPU-backed inference/training jobs submitted through the scheduler | [docs/GPU_WORKERS.md](docs/GPU_WORKERS.md) |
| Promoted listings | Sponsored/promoted marketplace placement for creator/business agents (future ad product) | `Agent.is_sponsored`/`sponsor_score`, `backend/app/db/models.py` |
Per-run usage (every `AgentRun`, billed when `pricing_model=per_run`) and
creator payouts (the creator's share of monetized activity) are the
mechanics underneath the platform/creator/marketplace subscription and
per-run lines above — see [docs/MONETIZATION.md](docs/MONETIZATION.md) for
the full breakdown of how each line is computed and split.
## User-Facing Routes (YourAIWebtop)
| Route | Purpose |
| --- | --- |
| `/` | Marketing landing page |
| `/login` | User login |
| `/register` | User signup |
| `/forgot-password` | Password reset request |
| `/reset-password` | Password reset confirmation (emailed link) |
| `/marketplace` | Browse public agents |
| `/marketplace/agents/{agentId}` | Agent detail with **Agent Action Console** (capability cards, action templates, 6-tab run surface) |
| `/app` | Authenticated app shell (redirects to creator dashboard) |
| `/app/desktop` | Desktop Home — the daily operating environment; Boards grid (favorite, search, templates, archive) |
| `/app/desktop/boards/{boardId}` | A Desktop Board's canvas — draggable/resizable widget grid with a persisted layout |
| `/app/creator` | Creator dashboard — runs, usage, recent activity |
| `/app/creator/revenue` | Creator earnings breakdown |
| `/app/agents` | Manage your agents — **6-step Create Agent wizard** with templates and launch checklist |
| `/app/developer` | Developer API key management (AgentForge Protocol) |
| `/app/billing` | Plans, subscriptions, transaction history, billing provider/pricing |
| `/app/integrations` | OpenClaw channel gateway status, channel list, attach agent to channel, send test message |
| `/app/operations` | Agent Operations Console — tasks, long-horizon goals, multimodal, traces, benchmarks, datasets, scheduler, GPU workers |
| `/admin` | Admin portal (role-gated) |
| `/admin/revenue` | Platform-wide revenue dashboard (admin only) |
| `/admin/marketplace` | Marketplace analytics dashboard (admin only) |
| `/admin/support` | Support ticket queue (admin only) |
| `/admin/data-platform` | Protocol Data Layer overview — usage/revenue/quality/channel/workflow ledgers across every tenant (admin only) |
| `/admin/billing/overview` | Combined billing overview — Stripe stats + payment method breakdown (admin only) |
| `/admin/billing/stripe-stats` | Stripe-specific revenue stats (admin only) |
## Developer API Routes (AgentForge Protocol)
The Protocol API is authenticated with a developer API key (see
[docs/API_PROTOCOL.md](docs/API_PROTOCOL.md)), not a user session:
| Method | Path | Description |
| --- | --- | --- |
| `GET` | `/v1/agents` | List public marketplace agents |
| `GET` | `/v1/agents/{agent_id}` | Get one public agent (`agent_id` is the numeric agent ID) |
| `POST` | `/v1/agents/{agent_id}/run` | Run an agent; returns the completed `AgentRun` |
| `GET` | `/v1/runs/{run_id}` | Fetch a run you created via the API |
API keys are created and managed at `/app/developer` in the web app, or via
`POST /api-keys` (user JWT). See [docs/API_PROTOCOL.md](docs/API_PROTOCOL.md)
for key creation, scopes, curl examples, and common errors.
## Runtime, Evaluation, and Trajectory Layer
Underneath both the marketplace UI and the Protocol API is the original
AgentForge agent runtime — this is what actually executes an agent run:
- **Agent swarm**: a planner → coder → evaluator loop
(`backend/app/agents/swarm.py`) that every marketplace/Protocol run is
composed into and executed through.
- **Multi-provider model router**: every agent run is dispatched through
`backend/app/model_router.py`, which selects a model provider (OpenAI,
Anthropic, Gemini, DeepSeek, OpenRouter) in priority order, tries BYOK
creator keys first, then platform-pool keys, then env-var single keys, and
falls back to a deterministic `LocalDeterministicProvider` if all real
providers fail. BYOK usage is recorded at zero cost; platform-key usage
is metered and written to `Transaction` for later billing. Provider health
is tracked in-process for status dashboards.
- **Sandboxed execution**: `auto`, `bubblewrap`, `docker`, and `local`
backends with timeouts, memory/CPU limits, output caps, network
disablement, and import blocklists (`backend/app/sandbox/runner.py`).
- **Event-sourced memory**: append-only `agent_memory.jsonl` records task
starts, steps, checkpoints, completions, failures, scheduler decisions,
multimodal events, and benchmark runs (`backend/app/memory/store.py`).
- **Long Horizon Agent goals**: persistent `/goals` objectives with
deterministic planning, step execution, reflection, replanning, and
pause/resume (`backend/app/goals.py`).
- **Observability**: Prometheus metrics at `/metrics`, in-memory traces at
`/traces`, trace IDs threaded through benchmark, scheduler, and run
records.
- **Evaluation loop**: a deterministic benchmark suite, benchmark history,
category scores, and a leaderboard — see [BENCHMARKS.md](BENCHMARKS.md)
for how this feeds each agent's marketplace `value_score`.
- **Trajectory export**: `/datasets/trajectories` and
`/datasets/trajectories/export` expose every run as a JSON/NDJSON record
with events, scores, sandbox results, and trace IDs — usable for
debugging, evaluation, or RLVR-style post-training research.
- **Distributed scheduling foundation**: a deterministic scheduler
simulation for CPU/memory/GPU availability, sandbox backend, worker load,
and placement policy — the contract a real worker fleet would plug into.
See [SYSTEM_DESIGN.md](SYSTEM_DESIGN.md) for how these layers fit together
with the Cloud/marketplace/protocol layers above them.
## OpenClaw Channel Gateway
YourAIWebtop fronts Telegram, Slack, WhatsApp, and other messaging channels
through a single gateway integration — **OpenClaw** — instead of every
business wiring each channel directly. Creators connect a channel and attach
an agent to it at `/app/integrations`; outbound messages are routed through
the approval workflow and billed as channel usage. Inbound automation
(real-time channel events launching agent runs, workflows, and approvals
automatically) is on the roadmap for Telegram, Slack, Discord, WhatsApp,
and Email — outbound messaging is the current implementation.
AgentForge's backend (`backend/app/channels/providers/openclaw_provider.py`)
is the only thing that ever talks to OpenClaw (`OPENCLAW_BASE_URL` /
`OPENCLAW_API_KEY`) — end users and creators never see OpenClaw's own
Control UI or credentials. Every outbound channel send goes through
AgentForge's own high-risk-action approval workflow and is billed as
**channel usage** (a premium unit multiplier on top of the run that
triggered it) and recorded in the Protocol Data Layer's `channel_events`
ledger. See [docs/OPENCLAW_INTEGRATION.md](docs/OPENCLAW_INTEGRATION.md)
(API surface, approval gating, billing) and
[docs/OPENCLAW_GATEWAY.md](docs/OPENCLAW_GATEWAY.md) (deploying OpenClaw,
secrets, why end users never need its Control UI).
## Protocol Data Layer
Every protocol-level action — agent runs, tool calls, channel sends,
approvals, support tickets/CSAT, subscriptions, and planner workflows —
is written through one function, `record_protocol_event()`
(`backend/app/events/protocol.py`), into a `protocol_events` table plus one
of seven specialized ledgers: `protocol_usage_ledger`, `revenue_ledger`,
`quality_ledger`, `workflow_events`, `channel_events`, `tool_call_events`,
and `support_events`. This is AgentForge's data middle platform: a single,
queryable, per-tenant-scoped event spine that the marketplace, billing,
admin, and Operations Console surfaces all read from, instead of each
feature inventing its own usage/revenue logging. Read via `GET /v1/*`
endpoints (JWT or API-key scoped to the caller) or the platform-wide
`/admin/data-platform` overview. There is no dedicated doc yet beyond the
schema in `backend/alembic/versions/0021_protocol_data_layer.py` and the
behavior covered by `backend/tests/test_protocol_data_layer.py`.
## Billing & Monetization
YourAIWebtop supports three billing modes, controlled by two env vars:
| Mode | `BILLING_PROVIDER` | `BILLING_MODE` | What happens |
| --- | --- | --- | --- |
| **Sandbox** (default) | `sandbox` | `sandbox` | No real payments; all transactions marked `sandbox_paid`. Default for local dev and CI. |
| **Wise Payments** | `wise` | `test` or `live` | Fully operational. Bank-transfer checkout via `/billing/wise/checkout`; supports subscriptions, creator payouts, payout reconciliation, payout tracking, payout history, and webhook synchronization. Payments are `pending` until a webhook or admin confirmation clears them. |
| **Stripe** | `stripe` | `test` or `live` | Stripe Checkout, Billing Portal, and webhooks — implemented and technically functional. Production activation pending business verification. Stripe Connect creator payouts are a future roadmap item. |
`BILLING_MODE=sandbox` always wins over the provider selection, so a
configured-but-unfinished provider can never accidentally take a live payment.
Tests never require Stripe — all Stripe SDK calls are mocked.
Plans (`free` / `pro` / `creator` / `enterprise`) carry monthly quotas for
web agent runs and Protocol API calls, enforced server-side before each
run; exceeding a quota returns `402 Payment Required` with the plan,
limit, used count, and an upgrade URL. See:
- [docs/MONETIZATION.md](docs/MONETIZATION.md): plans/quotas, platform/agent
subscriptions, per-run and API usage, model markup, BYOK vs platform
keys, creator revenue share.
- [docs/STRIPE_TEST_MODE.md](docs/STRIPE_TEST_MODE.md): creating Stripe
test-mode products/prices, configuring secrets, how webhooks work, and
switching to live mode later.
- [docs/BILLING_PROVIDERS.md](docs/BILLING_PROVIDERS.md): sandbox vs
Stripe/Wise/Lemon Squeezy/Paddle/Polar, and what real integration requires.
- [docs/BILLING.md](docs/BILLING.md): the provider abstraction, revenue
split, and endpoint reference.
## Local Development
Prerequisites: Python 3.12 and pip for the backend, Node.js for the frontend.
Docker is optional, for Docker sandbox testing and Compose deployment.
```bash
cd backend
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
SANDBOX_BACKEND=local uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload
```
```bash
cd frontend
npm install
npm run dev
```
Run the backend test suite:
```bash
cd backend
SANDBOX_BACKEND=local python -m unittest discover -s tests
```
Useful environment variables:
```bash
AGENT_MEMORY_FILE=./agent_memory.jsonl
AGENT_UPLOAD_DIR=./uploads
SANDBOX_BACKEND=auto # auto, local, bubblewrap, or docker
SANDBOX_TIMEOUT_SECONDS=5
SANDBOX_MEMORY_LIMIT_MB=128
SANDBOX_CPU_LIMIT=0.5
REDIS_URL=redis://localhost:6379/0
QUEUE_MODE=auto
JWT_SECRET=change-me
# Model provider router — set one or more; router tries in priority order
# (openai → anthropic → gemini → deepseek → openrouter), falls back to local
OPENAI_API_KEY= # sk-...
ANTHROPIC_API_KEY= # sk-ant-...
GEMINI_API_KEY= # AIza...
DEEPSEEK_API_KEY= # sk-...
OPENROUTER_API_KEY= # sk-or-...
AGENT_MODEL=gpt-4.1-mini # default model hint passed to the router
# Billing
BILLING_PROVIDER=sandbox # sandbox (default), stripe, or wise
BILLING_MODE=sandbox # sandbox (default); set "test" or "live" with a real provider
STRIPE_SECRET_KEY= # sk_test_... — only needed when BILLING_PROVIDER=stripe
STRIPE_WEBHOOK_SECRET= # whsec_... — see docs/STRIPE_TEST_MODE.md
STRIPE_PRICE_PRO_MONTHLY= # Stripe Price ID for the "pro" plan
STRIPE_PRICE_CREATOR_MONTHLY= # Stripe Price ID for the "creator" plan
WISE_API_TOKEN= # Wise API token — omit for instructions-only mode
WISE_PROFILE_ID= # Wise business/personal profile ID
WISE_DEFAULT_CURRENCY=USD
WISE_ACCOUNT_EMAIL= # shown in payment instructions
WISE_PUBLIC_KEY= # Wise RSA public key (PEM) for webhook signature verification
APP_PUBLIC_URL=https://youraiwebtop.com # used for Checkout/Portal redirect links
# OpenClaw channel gateway
OPENCLAW_BASE_URL= # OpenClaw gateway base URL
OPENCLAW_API_KEY= # OpenClaw API key
# Brevo transactional email (password reset) — see docs/EMAIL_NOTIFICATIONS.md
BREVO_API_KEY= # Brevo API key (free tier: 300 emails/day)
BREVO_SENDER_EMAIL= # verified sender address in your Brevo account
BREVO_SENDER_NAME=YourAIWebtop
APP_URL=https://youraiwebtop.com # used for reset-password links in emails
# Company Workspace real OAuth2 connections — see docs/COMPANY_WORKSPACE.md
# Any provider left unset shows as "not configured" instead of erroring.
GOOGLE_OAUTH_CLIENT_ID=
GOOGLE_OAUTH_CLIENT_SECRET=
MICROSOFT_OAUTH_CLIENT_ID=
MICROSOFT_OAUTH_CLIENT_SECRET=
MICROSOFT_OAUTH_TENANT=common # or a specific Azure AD tenant ID
SLACK_OAUTH_CLIENT_ID=
SLACK_OAUTH_CLIENT_SECRET=
NOTION_OAUTH_CLIENT_ID=
NOTION_OAUTH_CLIENT_SECRET=
HUBSPOT_OAUTH_CLIENT_ID=
HUBSPOT_OAUTH_CLIENT_SECRET=
SALESFORCE_OAUTH_CLIENT_ID=
SALESFORCE_OAUTH_CLIENT_SECRET=
SALESFORCE_LOGIN_URL=https://login.salesforce.com # https://test.salesforce.com for sandbox orgs
GITH_OAUTH_CLIENT_ID= # named GITH_ (not GITHUB_) because GitHub Actions rejects secrets starting with GITHUB_
GITH_OAUTH_CLIENT_SECRET=
DROPBOX_OAUTH_CLIENT_ID=
DROPBOX_OAUTH_CLIENT_SECRET=
```
None of the model provider keys are required for local development — agent
runs fall back to `LocalDeterministicProvider` when no real provider key is
set. Billing defaults to sandbox mode when no Stripe or Wise configuration
is present.
## Quick Demo Commands
Run the marketplace/Protocol agent runtime directly (no auth, for local dev):
```bash
curl -s -X POST "http://localhost:8000/agent/run" \
-H "Content-Type: application/json" \
-d '{"task":"run a safe sandboxed agent step"}'
```
Run the benchmark suite:
```bash
curl -s -X POST "http://localhost:8000/eval/run" \
-H "Content-Type: application/json" \
-d '{}'
```
Inspect trajectories:
```bash
curl -s "http://localhost:8000/datasets/trajectories?limit=5"
curl -s "http://localhost:8000/datasets/trajectories/export?limit=5"
```
Call the Protocol API with a developer key (see
[docs/API_PROTOCOL.md](docs/API_PROTOCOL.md) for creating one):
```bash
curl -s http://localhost:8000/v1/agents \
-H "Authorization: Bearer afp_your_key_here"
```
## Sandboxing and Safety
The sandbox is the boundary between agent-generated code and the runtime
process.
- `auto` selection tries Bubblewrap, then Docker, then local fallback.
- Docker execution disables networking, drops Linux capabilities, uses
`no-new-privileges`, applies CPU/memory/pid limits, mounts the task
directory read-only, and runs as an unprivileged UID/GID.
- Bubblewrap execution uses namespace isolation and read-only system binds
when `bwrap` is available.
- Local fallback uses isolated Python mode plus resource limits where the
host supports them.
- Static import blocklists reject obvious network/process imports before
execution.
- Every run returns stdout, stderr, return code, timeout status, duration,
and selected isolation backend.
This is a solid implementation for a private beta platform; production-grade
tenant isolation and stronger hostile-code containment are on the roadmap.
See [SECURITY_MODEL.md](SECURITY_MODEL.md) for known gaps and the hardening
plan.
## Roadmap
- **Production tenant isolation**: per-tenant sandbox credentials, rate
limits, and audit logging — see [SECURITY_MODEL.md](SECURITY_MODEL.md).
- **Production OpenClaw channel automation**: real-time inbound channel
events (Telegram, Slack, Discord, WhatsApp, Email) launching agent runs,
workflows, approvals, and long-running automation automatically.
- **AI Memory Platform**: persistent, structured memory across agent runs
and sessions.
- **Multi-agent orchestration**: coordinated execution across multiple
agents within a single workflow.
- **Enterprise knowledge connectors**: integrations with enterprise data
sources for agent context and retrieval.
- **Stronger sandboxing**: move beyond the current bubblewrap/docker
implementation toward a hardened multi-tenant hostile-code containment
boundary.
- **Distributed execution platform**: replace the current in-process
scheduler simulation with a real worker fleet (queue-backed, k8s/ECS/VM
pools, GPU inventory) — see [SYSTEM_DESIGN.md](SYSTEM_DESIGN.md).
- **Native iOS & Android applications**: mobile clients for the
YourAIWebtop marketplace and creator console.
- **Enterprise SSO**: SAML/OIDC single sign-on for enterprise plan tenants.
- **Advanced platform analytics**: cohort retention, revenue forecasting,
and agent quality trends beyond the current ledger views.
- **Stripe Connect creator payouts**: automated creator payout settlement
via Stripe Connect (Wise Payments creator payouts are already live).
- **Enterprise financial reporting**: advanced reporting for enterprise
billing and revenue reconciliation.
- See [docs/ROADMAP.md](docs/ROADMAP.md) for the full list.
## Documentation
- [docs/COMPANY_WORKSPACE.md](docs/COMPANY_WORKSPACE.md): the "Create My
Company" wizard — provisioning an AI workforce by department, Company
Profile, Company Memory, and team invites.
- [docs/API_PROTOCOL.md](docs/API_PROTOCOL.md): AgentForge Protocol — API
keys, scopes, `/v1` endpoint reference, curl examples.
- [docs/MARKETPLACE.md](docs/MARKETPLACE.md): marketplace access rules,
execution flow, usage/value-score tracking.
- [docs/BILLING.md](docs/BILLING.md): sandbox/Stripe/Wise billing, revenue
split, provider abstraction.
- [docs/MONETIZATION.md](docs/MONETIZATION.md): the full monetization model
(subscriptions, per-run/API usage, model markup, BYOK, creator share).
- [docs/BILLING_PROVIDERS.md](docs/BILLING_PROVIDERS.md): sandbox vs real
billing providers compared.
- [docs/STRIPE_TEST_MODE.md](docs/STRIPE_TEST_MODE.md): Stripe test-mode
setup, secrets, webhooks, and switching to live mode.
- [docs/OPERATIONS_CONSOLE.md](docs/OPERATIONS_CONSOLE.md): the Agent
Operations Console — what each panel shows and who it's for.
- [docs/OPENCLAW_INTEGRATION.md](docs/OPENCLAW_INTEGRATION.md): the OpenClaw
channel gateway API surface, approval gating, and channel-usage billing.
- [docs/OPENCLAW_GATEWAY.md](docs/OPENCLAW_GATEWAY.md): deploying OpenClaw,
secrets, and why end users never need its Control UI.
- [docs/OPERATIONS_PLANNER.md](docs/OPERATIONS_PLANNER.md): the multi-step
planner workflow surface and workflow-usage billing.
- [docs/PRODUCT_VISION.md](docs/PRODUCT_VISION.md): business model, creator
economy, long-term data moat.
- [docs/LONG_HORIZON_AGENT.md](docs/LONG_HORIZON_AGENT.md): goal lifecycle,
reflection loop, APIs, trajectory integration.
- [docs/ROADMAP.md](docs/ROADMAP.md): product and research roadmap.
- [docs/TEAM_NOTES.md](docs/TEAM_NOTES.md): engineering discussion notes
(sandbox security, orchestration, observability, trajectory collection).
- [docs/EMAIL_NOTIFICATIONS.md](docs/EMAIL_NOTIFICATIONS.md): Brevo
transactional email setup for password reset and notifications.
- [AGENTS.md](AGENTS.md): marketplace/creator/protocol agents, runtime
swarm, chat/task/multimodal modes, value score.
- [SYSTEM_DESIGN.md](SYSTEM_DESIGN.md): component-level system design,
Cloud/marketplace/protocol/runtime layers.
- [SECURITY_MODEL.md](SECURITY_MODEL.md): sandbox model, API key/JWT
security, known gaps, hardening plan.
- [BENCHMARKS.md](BENCHMARKS.md): benchmark suite and how it feeds agent
value scores.
- [docs/PROVENANCE.md](docs/PROVENANCE.md): source headers, build metadata,
the `/provenance` API, and the release-signing roadmap.
- [docs/SUPPLY_CHAIN_SECURITY.md](docs/SUPPLY_CHAIN_SECURITY.md): signed
commits, SBOM generation, GitHub artifact attestations, signed releases,
and the operational checklist.
## Supply Chain Security & GitHub Release Readiness
On top of the ownership/provenance signals above, the project also covers:
- Signed Git commits (GPG or SSH) and GitHub Verified-commit configuration.
- SBOM (Software Bill of Materials) generation, both locally
(`scripts/generate_sbom.sh`) and as a spec-compliant CycloneDX SBOM in CI.
- GitHub artifact attestations (Sigstore-backed) for the SBOM and the
frontend build, generated by `.github/workflows/deploy.yml`.
- An optional, additive release workflow (`.github/workflows/release.yml`)
that builds, SBOMs, attests, and publishes a signed GitHub Release.
Before tagging a release, run `./scripts/verify_supply_chain.sh` locally and
confirm: the `deploy.yml` run for the commit being released is green, signed
commits/attestations are present, and (if cutting a tagged release)
`release.yml` produced a GitHub Release with its SBOM and attestation
attached. See [docs/SUPPLY_CHAIN_SECURITY.md](docs/SUPPLY_CHAIN_SECURITY.md)
for the full setup, CI integration details, and operational checklist, and
[docs/PROVENANCE.md](docs/PROVENANCE.md) for what the provenance signals do
and do not guarantee. This repository has no public release history yet —
both workflows are wired and tested but have not been run against a tagged
release; verify end-to-end before cutting the first tagged release.
## Proprietary Status & Provenance
AgentForge Protocol is proprietary software owned by **ANAT Team**.
Copyright © 2026 ANAT Team. All rights reserved. There is no open-source
license attached to this repository — see [NOTICE.md](NOTICE.md) and
[COPYRIGHT.md](COPYRIGHT.md) for details.
Ownership and build provenance are signaled at multiple layers: short
copyright headers on project-owned source files, a `GET /provenance` API
endpoint, build-time `AGENTFORGE_BUILD_COMMIT`/`AGENTFORGE_BUILD_TIMESTAMP`
env vars wired through CI/CD, and a `scripts/check_provenance.py`
verification script. See [docs/PROVENANCE.md](docs/PROVENANCE.md) for the
full picture, including its limitations (these are signals, not
unremovable watermarks or access controls).
