Where the platform
thinks.

What it is

Reasoning sits between your agents and the models. Rather than call one model and hope, it runs a disciplined pipeline — route → extract → validate — that picks the right handler for the input, extracts structure, and checks the result against a schema before returning it. You get validated JSON, not a paragraph to parse.

On top of that sit two reusable units of work: skills (a versioned, testable prompt with an input and output schema) and chains (skills and prompts composed into a pipeline with conditionals, parallelism, budgets and guardrails).

Quickstart

1. Call a tool over MCP

Point any MCP-capable client at the endpoint and authenticate with an API key.

curl -X POST https://<YOUR_REASONING_HOST>/v1/mcp \
  -H "X-API-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
        "jsonrpc": "2.0", "id": 1,
        "method": "tools/call",
        "params": { "name": "list_skills", "arguments": {} }
      }'

{ "skills": [ { "name": "pm.generate_feature_spec_from_goal",
                "description": "Draft a feature spec from a goal | Category: pm/spec_generation | Model: balanced",
                "input_schema": { "type": "object", "properties": { … } } } ],
  "count": 1 }

2. Run a skill

curl -X POST https://<YOUR_REASONING_HOST>/v1/skills/run-by-name \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
        "skill_name": "pm.generate_feature_spec_from_goal",
        "inputs": { "goal": "Let users log in with SSO",
                    "constraints": ["must support SAML"] },
        "temperature": 0.7
      }'

{ "skill_id": "b1e7…", "skill_name": "pm.generate_feature_spec_from_goal",
  "skill_version": 3,
  "output": { "feature_name": "SSO Login", "acceptance_criteria": ["…"] },
  "execution_id": "8f2c…", "outcome": "success", "duration_ms": 1240,
  "model_used": "…", "tokens_used": 847, "validation_passed": true }

Authentication

Your organisation is always resolved from the validated credential. A user caller that names a different organisation in a request body is refused rather than served, and a service caller must name one explicitly rather than defaulting.

The MCP endpoint publishes OAuth discovery documents and supports dynamic client registration, so a spec-compliant client can connect without manual configuration. Tool calls are rate limited per organisation; concurrent sessions are capped.

MCP tools

Seventeen tools, every one annotated so your client can distinguish reading from writing before it runs anything.

Read — product & specification

Read — agent specifications

Write — status

Status writes are annotated non-destructive — full version history is retained, so a wrong status is correctable rather than lossy.

Skills

run_skill is deliberately annotated as destructive and non-idempotent — a skill can do anything, so the conservative hint is the honest one. It returns the output plus outcome, skill_version, execution_id, duration_ms, model_used, tokens_used and a trace id.

Tool errors come back as content with an error field rather than as transport failures, so an agent can read the reason and adapt — including when it has been rate limited or has reached across organisations.

MCP prompts

The server also publishes prompts — parameterised starting points a client can offer directly to a user:

Skills

A skill is a versioned, executable prompt with schemas on both sides. Defining one is a POST, not a deploy.

Endpoints

Model affinity

Different inputs deserve different models. Affinity binds a skill to an ordered model preference per context:

PUT /v1/skills/{skill_id}/affinity
{
  "affinities": [
    { "context": "simple",  "models": ["<fast-model>"],                    "priority": 0 },
    { "context": "complex", "models": ["<strong-model>", "<fallback>"],   "priority": 1 },
    { "context": "default", "models": ["<balanced-model>"],                "priority": 2 }
  ]
}

Models are tried in order; lower priority numbers win. Resolution runs: an explicit model_override on the call (validated against an allowlist), then affinity plus an automatic complexity assessment of the input, then the skill's declared tier, then the platform default.

The complexity assessor is lazy — it only runs when affinity rows exist, so the common path costs nothing.

Chains

A chain composes steps — a skill, a prompt, a raw model call, or another chain — into a pipeline.

POST /v1/chain
{
  "name": "spec_pipeline",
  "routing_mode": "cloud",
  "steps": [
    { "name": "extract_requirements", "step_type": "skill",
      "skill_name": "extract_goals" },
    { "name": "generate_spec", "step_type": "prompt",
      "prompt_template": "Given requirements: {{ previous_output }}\nGenerate a feature spec.",
      "system_prompt": "You are a senior product manager.",
      "uses_previous": true, "is_final_output": true }
  ]
}

A chain of skills

The useful pattern is composing skills rather than prompts — each step is separately versioned, separately tested and reusable somewhere else. A step can also be another chain, so a chain of skills becomes a building block in a larger one.

{
  "name": "intake_pipeline",
  "steps": [
    { "name": "classify",  "step_type": "skill", "skill_name": "doc.classify" },

    // fan out — both run concurrently, results merged
    { "name": "entities",  "step_type": "skill", "skill_name": "doc.extract_entities",
      "parallel_group": "enrich", "uses_previous": true },
    { "name": "summary",   "step_type": "skill", "skill_name": "doc.summarise",
      "parallel_group": "enrich", "uses_previous": true,
      "merge_strategy": "merge" },

    // only escalate when the classifier wasn't confident
    { "name": "deep_review", "step_type": "chain", "chain_name": "expert_review",
      "condition": { "field": "confidence", "op": "<", "value": 0.8 },
      "skip_on_condition_fail": true },

    { "name": "render", "step_type": "skill", "skill_name": "doc.render_report",
      "uses_previous": true, "is_final_output": true }
  ],
  "max_cost_usd": 0.50,
  "budget_enforcement": "downgrade",
  "on_failure_strategy": "abort"
}

Four things are worth noticing. Steps fan out by sharing a group and reconverge by merge strategy. A step skips itself when its condition fails, so the expensive review only runs when the cheap classifier was unsure. A step is another chain, which is how a library of small pipelines composes into a big one. And the whole run carries a budget — on downgrade it drops to faster models rather than failing, which is usually what you want at 3am.

Nesting is depth-bounded with circular-reference detection, so a chain that references itself is refused at execution rather than discovered as a stack overflow.

Returns final_output, every intermediate_outputs step, errors, total_tokens, execution_time and the models_used — note the plural: one chain routinely spans several models and providers, and the response tells you which ones actually served it.

The same run as server-sent events: chain_start, chain_step_start, chain_step_complete, chain_step_error, chain_complete.

Understanding pipeline

Underneath skills and chains is the primitive that turns text into structure. A unit is a semantic description plus typed slots; the description drives routing, the slots drive extraction and the schema.

Slot types cover strings, numbers, integers, booleans, typed arrays, objects, and formatted strings for date, date-time, email and URL, each with its own constraints.

Graph of Thought

Record why, not only what. Reasoning nodes form a directed graph and link to the entities they produced.

A node has a reasoning_type of observation, inference, decision, question or answer, plus content, a confidence, and parent nodes.

A design decision carries title, context, decision, rationale, alternatives considered and consequences, with a lifecycle of proposed → accepted · rejected · deprecated.

Semantic search across specification and code, filterable by component type and minimum similarity.

Reads are filtered to your organisation; a caller cannot walk another tenant's reasoning. These routes are service-to-service in shape — they expect embeddings supplied by the caller.

Events

State changes publish through a transactional outbox, so an event is committed with the change that caused it rather than best-effort afterwards. Consumption is idempotent through an inbox.

{ "type": "concept.updated", "version": "1.0",
  "timestamp": "2026-08-03T12:00:00Z",
  "event_id": "…", "idempotency_key": "…",
  "producer": "reasoning", "org_id": "…", "project_id": "…",
  "payload": { "concept_id": "…", "concept_type": "Feature",
               "properties": { "name": "My Feature", "status": "backlog" } } }

Webhook deliveries carry the event type, a stable idempotency key that survives retries, and an HMAC signature over the raw body. Delivery is at-least-once with exponential backoff and a bounded retry count before an event is marked failed — so consumers must be idempotent. Ordering is guaranteed per organisation, not globally.

Two idempotency concepts are separate on purpose: a transport key that is stable across retries of the same delivery, and a domain key that dedupes the same logical event.

Multi-model, multi-provider

No single model is right for every call, and no single provider should be a hard dependency. Reasoning treats the model as a routing decision made at call time, from four inputs: the tier a skill declares, its affinity rules, your tenant policy, and what is actually reachable right now.

Tiers, not model names

Skills declare a tier. Swapping the model behind a tier is a configuration change, not a rewrite of every skill that used it.

Providers

Self-hosted and cloud providers sit behind one interface, so a skill does not know or care which served it.

The registry knows which models a provider can actually serve — including whether a model is currently loaded on a self-hosted host. A request for a model that isn't there fails over instead of erroring.

Fallback is a policy, not a hard-code

Each tenant can define its own chain: a primary provider, then an ordered fallback list where every step names the conditions that trigger it.

{
  "primary": { "provider": "self-hosted" },
  "fallback_chain": [
    { "provider": "groq",
      "triggers": ["on_connection_error", "on_timeout", "on_5xx", "on_model_unavailable"] },
    { "provider": "openai", "triggers": ["always"] }
  ],
  "enabled": true
}

Errors are classified before the chain is walked, so a timeout and a bad request are not treated the same way — only the steps whose triggers match are tried. Set no policy and you inherit the platform default. A circuit breaker sits in front of every provider, so one that is failing is skipped fast rather than retried into the ground.

Per-skill affinity

Above the tier, a skill can bind specific models to specific contexts — and the input is classified as simple or complex on the way in, so an easy call doesn't pay for a hard model. See Model affinity. Precedence at call time: an explicit override, then affinity plus complexity, then the declared tier, then the platform default.

Reliability

Errors

Skill outcomes

Status codes

Every response carries a correlation id header — quote it when reporting an issue and the whole call is retrievable.

Your data

Reasoning processes the prompts, conversation turns and embeddings you send it, isolated per organisation and always scoped to the credential that made the call. It retains execution and usage records so you can see what ran, on which model, and at what cost.

Inference is local-first: your content is reasoned over by self-hosted models by default. When a request falls back to a cloud provider — or you configure one deliberately, including with your own provider keys — that prompt content leaves to that third party. Which providers, and what they retain, is set out in the privacy policy.

Availability & access

Reasoning ships as part of the SeKondBrain platform — licensed, not open source. It runs in production today behind our own products; you buy the platform and integrate the engine through its MCP surface and REST API, with your organisation provisioned and isolated for you.

Where it runs

What you get when you're set up