One prompt in. The right model, on the right miner, every time.

Four owned layers. One prompt nests through all of them.

Every request flows through the same funnel — Agent → Template → Task → Step — and each layer is selected dynamically. The concrete model and miner are bound only at the very bottom, at runtime.

1. 1Agent— A reusable, persistent expert

   A prompt is matched to the best existing expert — not built from scratch each time. The agent owns its rules, its workflows, and its general knowledge. A compound prompt fans out to one agent per facet.

   Matched by similarity + earned quality + live feasibility
2. 2Template— The agent's prompt protocol

   The agent's versioned recipe: which capabilities and phases run, in what order. It declares a workflow — a list of tasks — and is improved over time from graded outcomes and user feedback, behind a canary gate.

   Declares capabilities, never a model
3. 3Task— One unit of work

   A node in the run's execution graph. It carries capability requirements and policy — what kind of work this is and what it's allowed to use — not a model id. Tasks run in dependency order, in parallel where they can.

   Carries capability requirements, not a model
4. 4Step— The executable atom

   A tool call, a model call, or a delegation to another agent. This is the only place a concrete model and a concrete miner are bound — at runtime, by the scorer, from what the pool can actually serve right now.

   The single place model + miner are bound

Everything the layer handles so your code doesn't have to.

One layer, two audiences it was made for.

Every option, reachable from your existing SDK.

Everything the orchestration layer does is reachable through two OpenAI-compatible endpoints. Point your existing SDK at the gateway, pick how much state you want us to hold, and opt into agents, memory, tools, and reasoning depth per request.

curl -X POST https://YOUR_DOMAIN/api/v1/chat/completions \
  -H "Authorization: Bearer elis_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "elis/agent",
    "agent": "return_a_json_array_1",
    "store": true,
    "messages": [{"role": "user", "content": "Give three prime numbers."}]
  }'

# First turn — no previous_response_id
curl -X POST https://YOUR_DOMAIN/api/v1/responses \
  -H "Authorization: Bearer elis_xxxxxxxxxxxxxxxx" \
  -d '{"model": "elis/agent", "input": "Our launch date is 2026-09-01."}'

# Next turn — thread it; the server holds the context
curl -X POST https://YOUR_DOMAIN/api/v1/responses \
  -H "Authorization: Bearer elis_xxxxxxxxxxxxxxxx" \
  -d '{
    "model": "elis/agent",
    "input": "How many days until launch?",
    "previous_response_id": "resp_abc123def456"
  }'

Selection that gets better on its own — and proves it.

The layer doesn't just route — it learns which routes were good and adjusts. The loop is closed end-to-end and isolated per tenant.

1. 1

   Run & trace

   Every run persists a full trace — router selection, chain steps, tool I/O, model dispatch, miner choice.

2. 2

   Grade & collect feedback

   An automatic grader scores the output; the user's 👍/👎 and facet checkboxes (incomplete, too slow, off-topic…) route to specific signals.

3. 3

   Update per-layer quality

   Those signals move earned-quality EMAs on the agent, template, tool bundle, and model profile — the exact layers responsible.

4. 4

   Promote on merit

   A challenger template that beats its champion on real graded samples is promoted through a canary gate — never straight to full traffic.

5. 5

   The next request benefits

   Similar prompts now route to the improved expert and better-fit models. The loop is tenant-isolated: your feedback only ever tunes your routing.

Run it where your workload — and your auditors — need it.