The deterministic runtime for OAgents
AI agents quietly rewrite the values they pass around, run steps out of order, and re-bill every byte at token rates, because the model reads state it never needed to see. OyaAI runs OAgents on a deterministic runtime that closes that root cause, so they do real operational work reliably, run after run, with the full execution on record.
A standard ReAct agent passed all 15 benchmark tasks while silently corrupting ~81% of the critical identifiers. Passing tests is not the same as preserving state. That gap is the entire reason OyaAI exists.
What is OyaAI?
OyaAI is a runtime platform for OAgents: the agents your business runs for someone else. An SDR that runs outbound for a book of clients, a support agent answering your customers' tickets, an onboarding agent your product fires for every new account. The platform assembles the agent: a soul (persona plus behavior rules), the skills it needs (web search, email, Slack, your CRM), the routines that run on a schedule, and the knowledge base it consults. Each OAgent gets a chat surface, an OpenAI-compatible API key, webhooks, and integrations into wherever your work happens, and runs continuously in an isolated sandbox where every step is recorded and replayable.
This is the artifact you hand your customer when they ask why the agent did something. Not a log you paraphrase after the fact: the exact trace, replayable step by step, showing every value the agent read and every action it took. Nobody else in this category can give you one.
The problem we are solving
Most AI agents today are prompt wrappers around an LLM. They demo well and break in production, because token-only systems are non-deterministic: the same input can take a different path, retries cascade, and small drift compounds across a long workflow. Three failure modes do the real damage:
- State corruption: values get silently rewritten as they pass through the model. A URL's
.iobecomes.com, an ID's digits transpose, and the agent acts on the corrupted value with no exception raised. - Ordering drift: steps that must run in sequence (validate, then send) get interleaved or skipped, because the model chooses the next action from a partially-observed context.
- Token waste: every intermediate value flows back through the model and is re-billed at token rates, even values it never needed to read. Cost scales linearly with workflow length.
All three share one root cause: the model read state it should never have read. OyaAI fixes it at the architecture level. A planner emits one typed plan; a deterministic runtime executes it and passes values from skill to skill by reference, so a value the agent does not need to read never re-enters the model, and cannot be corrupted, reordered around, or re-billed. Roughly 20% of work runs on tokens and the other 80% is structured, deterministic compute, and every run is recorded and replayable. That is the difference between a demo and an OAgent that handles real load.
Measured against six published agent frameworks
Critical values preserved byte-for-byte: OyaAI vs a ReAct loop, across six models.
Perfect asymmetric score on all three frontier models. Every published framework scored negative on at least two of three.
Fewer LLM tokens per task than the leanest token-loop baseline (4-5x on every model).
% of critical values that survive byte-for-byte
Total tokens billed per benchmark task
Results are from our paper Plan, Don't React: Projection Types for LLM Agent Runtimes, evaluated on the open PlanBench benchmark (120 projection-annotated tasks) with the MIT-licensed oya-planner runtime, across GPT-5, Claude, Gemini, and GLM. The worst-case ReAct run passed every task while corrupting ~81% of the critical identifiers: a green test suite a customer would already have paid for.
Why OyaAI
80% structured compute, 20% tokens
LLMs handle reasoning. Everything else (data fetching, schema validation, scheduling, integrations, file IO, retries) runs on deterministic infrastructure. Same input, same path, run after run. In our benchmark that comes out to ~4.7x fewer LLM tokens per task than a ReAct loop, because the runtime passes values by reference instead of re-reading them into the model.
State and order stay correct
The runtime executes a typed dataflow plan, so values cannot be rewritten in transit and steps cannot run out of sequence. The two failure modes that quietly corrupt agent output (read-induced edits and ordering drift) are handled by the platform, not by a reminder in the prompt. In testing, critical values survived byte-for-byte 100% of the time versus 19-81% under a ReAct loop.
Secrets never reach the model
Credentials and sensitive data live in the deterministic layer, not in the prompt. Skills authenticate inside an isolated sandbox; the model sees results, not API keys or raw PII. Because the planner never reads opaque values, a class of indirect prompt-injection payloads cannot reach it either. Data isolation is structural, not a reminder in the system prompt.
Skills are the deterministic primitives
Every integration is a versioned skill in a catalog: Python in an isolated sandbox with a typed input/output schema. Drop them into an agent like LEGO. When something is missing, write a 50-line skill, import it, and reuse it across every future agent.
One identity, many channels
The same OAgent chats in your web app, replies on Slack, takes Telegram messages, fires on webhooks, and runs scheduled jobs. One memory, one personality, one API key.
No black box
Read every persona, behavior rule, skill, and routine an agent uses. Run history replays the full LLM trace, tool calls, and sandbox stdout for any run. Export any agent as a YAML spec and version it in git.
Run your worst-behaving workflow on both.
Same task on OyaAI and on your current framework. Diff the traces line by line, and see which one preserved state and which one quietly rewrote it.
Compare the tracesNew to OyaAI? Build your first OAgent in the Agent Builder, or start from a pre-built OAgent in the gallery and customize it.
Who this is for
A fit
- Agents in the customer-facing revenue path. When the agent breaks, you lose a client, not an afternoon.
- Teams where tokens are cost of goods sold, not an expense line. Model spend comes straight out of gross margin.
- Agent-native product companies (AI SDR, support, recruiting), agencies and dev shops shipping agents for clients, vertical AI wrappers with a book of business, and platform companies embedding agents into existing software.
Not a fit
- Internal-productivity deployments, where an agent saving your own team time is the whole point and no client sits on the other end.
- Pre-production prototypes, where determinism is not the constraint yet and you are still proving the workflow out.
We do not run a cold enterprise procurement motion. We reach enterprises through the agencies and integrators who serve them. If that is you, start with Partners.
Pick your path
Three audiences, three focused manuals.
Product
Create, configure, and operate OAgents. Oya Engineer builder, evals, channels & apps, routines, monitoring, and billing.
- Oya Engineer builder
- Evals & auto-improve
- Channels & Apps
- Monitoring & traces
Developers
Integrate OyaAI into your code. CLI, OpenAI-compatible API, skill authoring, MCP, webhooks, and GitHub versioning.
- Claude Code CLI
- API Keys
- Custom skills
- Triggers & webhooks
Partners
Run OyaAI as an agency: one account across every customer, one bill, and per-client cost visibility on every engagement, instead of reconciling model spend across ten vendor invoices with no idea what any single client costs to serve.
- Agency mode
- Account CLI
- Template authoring
- Consolidated billing