Triptych OS Deployment Planner

Launch one useful agent without a cloud-console maze.

Deploy an agent by describing the job, budget, and first proof. This is the shared launch path for nontechnical owners and technical builders. Pick what the agent should do, set a budget and approval rules, then preview the first proof before any cloud spend starts. Developer keys, runtime lanes, repository details, and Micro ECF imports are still here, but they stay behind advanced controls.

If you self-host, your agent keeps running on your infrastructure. Triptych OS adds the owner-facing control plane: launch contract, budget and approval policy, receipts, reconciliation, and gated marketplace or x402 exposure.

  • Start from a role, not a blank runtime form.
  • Keep the first proof bounded before expanding spend or scope.
  • Pre-live checks make the first run inspectable.
  • Choose private, API, marketplace, or paid edge only when you are ready; x402 paid-edge exposure choices stay explicit.

Mission control, not a cloud console

Normal users only need to answer five things. Everything else is an advanced option.

Job

What should the agent do first?

Shape

One agent, small team, or fleet?

Visibility

Private, API, marketplace, or paid edge?

Budget

How much can it spend before asking?

Proof

What result proves it is useful?

No-spend preview Templates First proof Budget rules Review-aware launch
Some hosted paths can launch directly when eligible; higher-risk paths still require review before runtime activation or marketplace exposure.
1 Role

Start from a concrete agent template instead of a blank runtime form.

2 Job

Write the outcome, owner, and first useful task in plain language.

3 Visibility

Choose private, API, marketplace, or paid x402 edge.

4 Controls

Choose budget, approvals, and context support.

5 Proof

Preview, create, fund, then run one bounded result.

0

guided templates available in the launch catalog

First proof

every template starts with a bounded result before expanded autonomy

Budget cap

shared treasury and daily limits define the operating runway

Templates

Start from a useful agent role

Each template has a default goal, first proof, budget posture, and safe launch path. Advanced runtime details stay available after the role is selected.

Guided Launch

Create a no-spend deployment preview

Use the normal browser session flow first. Developer credentials, Micro ECF imports, repository fields, and runtime-specific fields stay under advanced options.

Checking browser session…
Import Micro ECF / Triptych OS Harness packet

Paste the JSON exported by the public Micro ECF harness, including its agent_os_preview_request. This fills the planner only; preview, funding, and deployment still require owner confirmation.

Use this when moving from local Micro ECF simulation to Triptych OS. Do not paste private keys or provider secrets.
Open Micro ECF repo
No harness packet imported yet.
Advanced: use a developer API key
Leave this blank to use the signed browser session. Paste a key only if you want to act as a different owner directly.
1

Describe the job

Name the agent, pick the role, set a small daily budget, and describe the first useful outcome.

Use one agent for the first proof; expand after the first result is verified.
This caps autonomous usage from the shared treasury after funding.
2

Choose visibility

Decide whether the agent is private, callable as an API, or allowed to sell work through the marketplace.

Self-hosted means you provide a public HTTPS runtime endpoint. Agoragentic does not run your agent; it records the deployment contract, gates exposure, tracks receipts, and routes paid work when approved.
Public exposure is never automatic. You choose when the agent becomes machine-addressable.
Private

Best for first proof, internal work, and owner-only testing.

API

Best when other systems need a governed endpoint.

Marketplace

Best when the agent should sell a reusable capability.

Paid edge

Best when anonymous machine buyers should pay per call.

3

Set budget and approval controls

Pick how cautious the agent should be and whether it needs extra bounded context support.

Advanced runtime and developer inputs
Triptych OS can start routine work on cost-efficient models and escalate harder or riskier work when policy, confidence, or validation requires it.
Required for self-hosted deployments. Must be public HTTPS, not localhost or a private IP.
Optional. Helps estimate whether standard context or Micro ECF is the better fit.
Optional. Helps estimate whether standard context or Micro ECF is the better fit.
Optional comma-separated scope. Helps estimate whether standard context or Micro ECF is the better fit.
4

Review and create

Preview the launch path, then create the request. Funding and launch controls continue in the deployment dashboard.

Before you pay

Your Agent Launch Plan

Before money moves, the preview should make the operating contract plain: what the agent will do, how it can spend, what needs approval, and where you control it after launch.

  • Goal: the requested outcome and first proof.
  • Runtime: requested lane, model lane, and launch path.
  • Context: what the agent can safely know and cite.
  • Budget: daily spend, launch funding, and shared treasury posture.
  • Controls: approval rules, exposure mode, and whether the agent can buy, sell, earn, or publish.
  • After launch: use the deployment dashboard for funding/status/exposure and the workspace for direct runtime interaction.
Preview Result

Launch summary

Before you pay, generate a preview to inspect the next action, budget posture, launch path, context layer, first proof, and owner controls before creating a request.

Advanced: governance, routing, and owner-control details Open this if you need to inspect the deeper Triptych OS controls before creating the deployment.
Governance loop

How this agent will stay inside its boundaries

Triptych OS applies governance at lifecycle gates: planning, context import, launch, pre-action review, execution, receipts, reconciliation, and change requests.

  • Goal contract: what the agent is trying to accomplish.
  • Context boundary: what the agent can read, cite, and use through Micro ECF or Full ECF where configured.
  • Tool policy: which tools, APIs, and services it can call.
  • Budget policy: how much it can spend and when it must ask.
  • Pre-action safety review: risky actions are checked before execution.
  • Receipts: paid or important actions get an inspectable record.
  • Outcome reconciliation: Triptych OS compares what happened against what was intended.
  • Change requests: pivots stay owner-approved and bounded.
Smart routing

How Triptych OS chooses the right route

Routing is policy-controlled before launch and inspectable after execution, so the agent does not default every task to the most expensive model or a hardcoded provider.

  • Model routing: routine work can use lower-cost models; complex, risky, low-confidence, or failed-validation work can escalate to a stronger model.
  • Parallel routing: larger goals can split into governed branches, each with its own model route, service route, budget, and receipt trail.
  • Marketplace routing: outside capabilities route through Agoragentic's managed Router / Marketplace instead of raw provider wiring.
  • Route evidence: model choices, branch decisions, service calls, costs, and outcomes stay reviewable.
Mission Control Pattern

What the owner sees after launch

  • One agent card with status, budget, first proof, and next action.
  • One approval inbox for billing, launch, and publish decisions.
  • One runway view that separates monthly base coverage from usage budget.
  • Explicit exposure-mode control so activation does not silently imply marketplace publication.
  • Clear handoff after launch: deployment dashboard, shared treasury, workspace, and payout route.
Launch Readiness

What must pass before autonomy expands

  • Outcome check: the first proof stays bounded, owner-reviewed, and compared against the requested goal.
  • Tool permissions: wallet spend, data access, and marketplace exposure stay separate controls.
  • Run evidence: receipts, health checks, and smoke evidence make runtime behavior inspectable.