Resources · Runtime
The Myna Runtime
Follow the inbound message as it runs through the harness.
-
01 · Inbound
A message arrives
Receive a message from any connected channel.
-
02 · Pre-gates
Checked before any model runs
Duplicates, opt-outs, a teammate's takeover, channel compliance, message caps and business hours are checked in code first.
-
03 · Context
Context, assembled in modules
Your instructions never become one giant prompt. Objective, persona, tool policies, channel guidance, knowledge and corrections are separate modules, and each stage reads only what it needs.
-
04 · Planner
The planner reasons, then calls its tools
The planner works out what the customer needs and calls tools by name. It reads what they return and decides again, for a few steps at most, and it never writes a word the customer sees.
-
05 · Tool evidence
Tools return evidence
Each tool fills in its own input arguments from the conversation and returns typed output: evidence, not a message. That evidence goes back to the planner for its next decision, and on to the composer.
-
06 · Composer
One composer writes the reply
A single composer writes the reply from confirmed evidence only. Its voice comes from the persona. Its length and layout come from the channel policy.
-
07 · Post-gates
Checked again before it sends
Deterministic checks validate every claim in the reply against tool evidence. A failing reply gets one repair pass, then falls back to a safe response.
-
08 · Send
Send, then land
After the agent sends its message, land the contact in the right place on a multi-step workflow. Routing uses deterministic conditions, with graph verification and full tracing.
Guarantees
What the runtime promises, every turn
- 01
Tools never send
Only the runtime sends, and only after the post-gates approve. A tool built to send a message can't even be registered.
- 02
Tools can be removed, never added
Each layer can only narrow what's available. A tool that isn't enabled for this turn is refused, even one that only reads.
- 03
One change per step
At most one tool that changes data runs per step, and a call that already succeeded returns its result instead of running twice.
- 04
No false confirmations
A failed booking, move or handoff can never come out as “done.” The reply can only claim what a tool proved.
- 05
A bounded loop
Planning runs a small, capped number of steps. Any tool failure ends it, and the reply still goes out, honestly.
- 06
Takeover means silence
When a person takes over, the agent stops before any model runs. Messages still reach your team.
- 07
A fixed order of priority
Safety, then truth and your instructions, then the channel, then the persona's voice. Corrections shape wording, never facts.
- 08
Facts come from records
Contact fields, answers, appointments and tickets are read from structured state every turn, not remembered from the transcript.
Coming soon
The Myna ADK
Define the same agents you build in Workflow Studio in code: personas, tools, calendars, knowledge and evals, in your own repo. Deploy to drafts, test them on the real runtime, and publish when you're ready.
The ADK declares. The runtime decides.
You write the agent. Myna runs it: hosting, every channel, every gate and guarantee above.
Build in Workflow Studio todayimport { defineAgent, agentNode, builtin } from '@mynacx/adk'; export default defineAgent({ name: 'front-desk', template: 'schedule-appointments', persona: ava, channels: { sms: { number: '+15555550123' }, webchat: {} }, workflow: { start: agentNode({ instructions: 'Help patients book cleanings and consults.', tools: [builtin.searchMemory(), builtin.offerAppointment(), builtin.scheduleAppointment()], }), },});What you define
-
agents/Channels, hours and the workflow an agent runs -
personas/Mixer levels, or a voice the Emulator learns from real messages -
workflows/Steps with instructions, tools and policies -
tools/Your own tools, with the same contracts as the built-ins -
calendars/Booking rules, where the description does the routing -
knowledge/Files and pages your agent answers from -
corrections/Reviewed feedback, kept in code and pull requests -
evals/Behaviour tests: tools called, outcomes, gates fired
From a folder to a live agent
-
myna initStart from a template -
myna devDeploy drafts and test on the real runtime -
myna evalRun behaviour tests against the draft -
myna publishTake config and workflow live together
Questions about the runtime
Something else on your mind? The documentation has the details.
Read the documentationWhat is the Myna runtime?
It's the harness every Myna agent runs on. For each message it runs pre-gates, assembles context from modules, lets the planner call tools, composes one reply from the tool evidence, runs post-gates, and only then sends. The same runtime serves every channel.
Does the model that calls tools also write the reply?
No. Planning and writing are separate stages. The planner reasons and calls tools by name, tools return typed evidence, and a single composer writes the reply from that evidence. Only the runtime sends, after the post-gates pass.
How does the runtime keep replies accurate?
The composer works from confirmed tool evidence only, and deterministic post-gates validate every claim in the reply against that evidence. A failing reply gets one repair pass, then falls back to a safe response.
What runs before the model?
Pre-gates. Duplicates, opt-outs, a teammate's takeover, channel compliance, message caps and business hours are all checked in code before any model is called.
Do I need to write prompts?
No. You write instructions, choose a persona and select tools for each step. The runtime assembles them into the prompt each stage needs, so you never write or maintain a system prompt.
Is there a developer kit?
The Myna ADK, a code-first way to define agents, tools and evals, is coming soon. Today you build agents in Workflow Studio, on the same runtime.