Skip to main content
Mirobody exposes the same grounded health agent through two surfaces. Both answer from the Subject’s real, standardized health data, and both return the tool trace behind the answer. Both are ③ Agent, the third of the engine’s three stages (① Collect → ② Translate → ③ Agent). The choice is who drives the loop: the Answers API returns a completed answer, while the Agent API lets your tools take part. A self-hosted engine offers a bundled agent and an /mcp endpoint for your own agent loop. That design choice carries over if you run the engine yourself; the requests and credentials do not. Cloud uses /v1 and a Cloud key, while self-hosted integrations use the deployment’s HTTP API or /mcp.

Answers API

POST /v1/chat/completions — closed, one-shot, evidence-backed completions. No client tools, no state. Drop-in OpenAI swap.

Agent API

POST /v1/responses — OpenAI Responses-compatible. Multi-turn state, your own function tools, response.* streaming.
The Answers API speaks the older Chat Completions protocol and stays deliberately closed — no client tools, no stored state, chat.completion.chunk streaming only. That’s what lets it drop into an existing OpenAI integration unchanged, or wrap as a single tool inside a larger agent. The Agent API speaks the newer Responses protocol: state between turns (store, previous_response_id, session_id), your own function tools with a full function_call handoff, response.* events. It is what the openai-agents SDK talks to out of the box — change only the base_url. Everything else is identical: the same server-side grounding over your standardized data, the same mirobody-flash / mirobody-expert models, the same Subject-based tenancy, the same usage accounting.

​
See also