Put agents on the revenue path, not next to it.
Demos live in a sandbox. Revenue lives in your quotes, your invoices, your onboarding, your support queue. Oya is the runtime for the second kind: agents that hold state across runs, act through real accounts, and leave a record of every action so you can put them somewhere that matters.
Free credits to start, no card required · Usage-based after that, itemized per run
The work that has a customer on the other end.
An agent writing draft copy can be wrong quietly. An agent touching an invoice cannot. The difference is not model quality, it is what happens on the second run, the tenth, and the one at 3am when the API returns something unexpected. These are the jobs Oya is built for.
New customer to first value
Provision accounts, send the right welcome sequence, chase the missing form, and remember exactly where each customer is so nobody gets the same email twice or stalls halfway through.
Triage that reads the account
Classify the inbound, pull the account context, answer the ones with a clear answer, and escalate with the history attached instead of handing a human a blank ticket.
Follow-through nobody enjoys
Reconcile, chase, remind, report. Repetitive work with real money attached, where a double-send or a dropped identifier is the whole problem and correctness beats cleverness.
Most agents fail on the second run.
The first run is a demo and it always looks good. Production is the thousandth run: state from last week, a rate-limited API, a half-finished job, a schema that changed under you. A framework hands you primitives for that. A runtime handles it. The design behind that, and the measurements, are in the white paper.
- State drifts between runs. An identifier comes back subtly different and the next run acts on the wrong record
- Retries duplicate work. A timeout mid-run means the email goes twice and the charge posts twice
- Failures are silent. The run ends, nothing errors, and the work simply did not happen
- Nobody can reconstruct it. A customer asks what happened and the answer is a shrug
- State preserved across runs, so what the agent knew last time is what it knows this time
- Isolated sandbox execution, so skill code runs somewhere real without touching your machines
- Failures surface as failures, with an alert that says which step went wrong and why
- Every run recorded: inputs, tools called, output, and cost, kept per run
Your agent works where your team already does.
An agent on the revenue path has to reach the systems the revenue runs through. Connect an account once and reuse it across every agent, with credentials held by the platform rather than pasted into a prompt.
Ship one agent, then judge it.
Start with a single workflow you already understand well enough to know when it is wrong. That is the one worth automating first, and the one that tells you whether the rest belongs here.
Describe the job
Say what the agent should do in plain language. The builder turns it into an agent with the skills it needs, or start from a template and adapt it.
Connect what it touches
Link the accounts it acts through and give it a trigger: a webhook from your systems, a schedule, or a message in Slack. Test it before it goes anywhere near a customer.
Watch the runs
Every run is recorded with its inputs, tools, output, and cost. Failures alert you rather than passing silently, so you find out from the platform and not from the customer.
Put your first agent somewhere that counts.
Free credits to start and no card required, so the first agent costs you an afternoon rather than a budget line. Pick the workflow you would notice going wrong, and see whether it holds.
Governed deployments
If your agents run under compliance requirements, or need to stay inside your own cloud with your own model endpoints, that is what Oya Enterprise is for.
See Oya Enterprise