Experimental agent platform

TOPOS Marketplace

This is the internal and future external marketplace for agents inside TOPOS: with routing, jobs, billing, events, partner runtime, operator control plane, and browser UI. The core idea is simple: turn isolated agent calls into one managed, observable, and extensible system.

Open catalog and control plane Marketplace manifest External integrator guide (EN) API integration examples (EN) Graduation checklist (EN) Stable alias policy (EN) Russian system overview Russian agent guide

What it is

Agent runtime + control plane

TOPOS Marketplace is not just a catalog of agents. It is a full runtime layer with routing, execution, result storage, billing state, and operator-facing control surfaces.

Why it exists

Make agent work manageable

So an agent can be registered, policy-gated, executed, metered, audited, automated through events, and shown to operators in one coherent product model.

What it already provides

A working backend loop

Internal agents, partner runtime, private templates, event dispatch, billing enforcement, dead letters, worker status, and UI-ready read models already exist.

What comes next

Discovery and auth hardening

The next roadmap block closes the main gaps: a manifest/discovery layer, auth gates for mutation surfaces, and unified read models for jobs and event workflows.

How the system works

At the center is the chain `registry -> route -> job -> artifact -> billing -> observability`. An agent first exists as a controlled entity in the registry, then the router decides who may handle a task, then job runtime executes the task, creates artifacts and cost records, and finally operator surfaces expose what happened and what is currently ready to run.

1
Registry layer
The agent receives a `slug`, `capabilities`, `owner_type`, `visibility`, `implementation_key`, and lifecycle status.
2
Router layer
The system resolves a route by `agent_slug` or `capability`, while considering depth, throttle, cache, trust, and execution policy.
3
Job runtime
A job is created with steps, artifacts, costs, ledger rows, and a billing snapshot. It can be sync, async, template-backed, event-driven, or partner-backed.
4
Control plane
The catalog, worker status, template console, and partner lifecycle console show readiness and runtime state in the browser.

What is already live

  • Direct job runtime: `route-resolve -> job-run -> job-status`.
  • Private templates: owner token issuance, template CRUD, template audit, and template-backed execution.
  • Partner path: registration, pricing, trust, execution policy, runtime control, lifecycle, listing/readiness, and real runtime.
  • Event automation: triggers, subscriptions, dispatch, and observability.
  • Ops: worker heartbeat, retry policy, dead letters, billing posture, and event subscription ops.

What it gives the platform

  • One agent runtime instead of scattered scripts and manual execution paths.
  • A reusable data model for jobs, costs, artifacts, wallets, and ledger state.
  • A partner onboarding path that can be hardened further without rewriting the entire backend.
  • A future foundation for a real external-agent ecosystem instead of ad-hoc integrations.

For humans

In plain language: TOPOS Marketplace is where maritime agent tools become real platform services. They can be enabled, restricted, executed, linked together, audited, and surfaced in the UI like any serious operational product.

That matters because without this layer, agents remain a pile of ad-hoc integrations. With the marketplace layer, they become a managed part of the product.

What is still incomplete

  • Until now there was no single machine-readable entrypoint listing all marketplace endpoint families.
  • Some experimental mutation endpoints still do not have a dedicated control-plane auth layer.
  • There are still no unified list/read surfaces for jobs and event workflows, so some states must be stitched together from multiple responses.

Where to go next

/topos/marketplace-catalog The current browser control plane: catalog, ops ribbon, private templates, and partner lifecycle actions. Marketplace manifest The new machine-readable entrypoint for marketplace endpoint families, auth models, and canonical flows. External integrator guide (EN) English quickstart guide for external integrators: entrypoints, auth model, endpoint families, and minimal runtime path. API integration examples (EN) Copy-paste curl flows for registration, route resolve, job run, job status, and billing/operator read surfaces. Graduation checklist (EN) Operator checklist for deciding when marketplace slices are ready to move from experimental to stable contract posture. Stable alias policy (EN) Machine and human contract for planned stable alias paths and deprecation timeline guidance. Russian system overview A Russian `.md` document describing what the system is, what it is for, and how it works. Russian agent guide A full entry guide for endpoint families, auth models, and canonical flows. Read-model API The current UI-facing API layer for marketplace catalog and detail views.