Back to home

The platform underneath

Koru Runtime

Every agent we build runs on Koru Runtime. It records each run, checks tool permissions and enforces approval rules. Host the platform in your environment or have Koru operate it.

You own the agents we build for you. The platform and its operating terms are defined separately in your engagement.

Architecture

One boundary. Nothing crosses it unless you say so.

This diagram shows a customer-hosted deployment. The runtime, traces and knowledge indexes sit inside your network. A hosted model call crosses that boundary if you choose an external provider.

Koru Runtime deployment architecture Koru Runtime, its orchestrator, tool gateway, trace store and knowledge index all sit inside your network boundary alongside your own systems and, optionally, self-hosted models. The only path out of the boundary is an optional call to a hosted model provider using your own API key. YOUR CLOUD, OR YOUR DATA CENTRE Koru Runtime Orchestrator routing + approvals Tool gateway MCP + HTTP tools Trace store audit + replay Knowledge index your data Your systems ERP, CRM, ticketing, file stores Databases and data warehouse Identity provider (SSO / SAML) Reached with scoped credentials Models you run Open-weight models on your own hardware Nothing leaves the boundary. Works fully air-gapped. optional Hosted model provider Your key. Your account. Retention terms reviewed. Only if you choose one. No Koru-hosted service in the path. Your data is never routed through us.

Running fully managed instead? The runtime and records sit in a Koru-managed environment. See all three deployment models →

Capabilities

The infrastructure behind the agent you receive.

Orchestration

Every handoff has an owner.

A transfer changes which agent owns the run. A delegation sends out a task and returns its result to the original agent. The runtime checks permitted routes before either handoff.

  • Permitted routes are defined before an agent runs and checked when it hands off
  • Depth and cycle limits keep cross-agent work bounded
  • Routing decisions are recorded with the run
Observability

Trace the action back to its cause.

When an output needs review, the run record shows what the model asked for, which tools ran and where work passed between agents.

  • OpenTelemetry spans for model calls, tool calls and handoffs
  • Execution timeline with inputs, outputs and usage per step
  • Checkpoint replay for investigation without repeating completed actions
Evaluation

Test a change before it reaches a live workflow.

One passing example is too small a release test. Compare versions against representative tasks before promotion, then watch the result after release.

  • Run evaluation cases against a proposed version before release
  • Compare task results and running costs across model choices
  • Keep versions so a regression has a clear rollback path
Control

Put a person at the consequential steps.

Set approval rules on specific tools and actions. The agent gathers context on its own. Mark a write or send for review, and the runtime waits for the designated person.

  • Approval requests route to the designated reviewer
  • Unattended runs deny actions that require an unavailable approver
  • Approvals and denials are part of the run record
Models

Choose the model per task.

Set a model policy for each task and a fallback for provider failures. We test the result, then review cost and the data path with you.

  • Model selection per agent or task
  • Fallback routing for provider or model failures
  • Usage and cost visible in execution records
Integration

Agents act on your systems through your own auth.

An agent needs access to the tools your team already uses. Koru Runtime connects through scoped credentials and your existing access controls. It does not need a separate copy of your data.

  • Native MCP server support, plus HTTP tool definitions for anything without one
  • Credentials are added when tools run, so the model never sees keys or tenant identifiers
  • Event triggers and schedules, so agents run on your systems’ activity, not a cron you babysit
Delivery

Put an agent where the work happens.

Trigger an agent from an application, an event or a schedule. Use the streaming API for product features and scheduled runs for unattended work.

  • Streaming API for product integrations
  • Event and scheduled triggers for unattended work
  • Embeddable interfaces for customer-facing agents
Knowledge

Answers come from your data, with a citation back to the source.

The agent retrieves answers from your systems of record and links each answer to the document or row it used.

  • Indexes are built and stored inside your environment
  • Collection access inherits the permissions your systems already enforce
  • Every answer carries a link back to the document or row it came from
Security

Access control that matches the rest of your stack.

The platform uses role-based access and single sign-on. It also keeps an append-only audit log in every deployment model.

  • RBAC, SSO and SAML against your existing identity provider
  • Encryption in transit and at rest, with your own KMS keys where you want them
  • Append-only, exportable audit log covering every run, approval and configuration change

Model choice

The model is a setting, not an architecture decision.

The agent's model is a policy setting in Koru Runtime. Switch providers without rebuilding its tool integrations. Test the new model against the same evaluation cases before release.

Frontier models, your key

OpenAI, Anthropic, Google, Azure OpenAI and others. We review provider retention, account and credential choices with your team.

Open-weight, your hardware

Llama, Mistral, Qwen and similar, served inside your network. Nothing leaves the boundary, and the model cannot be deprecated out from under you.

Different model per task

A cheap local model for classification, a frontier model for the hard reasoning step. Routing and fallbacks are configuration.

Where it runs Compare your cloud, your data centre and Koru-managed hosting. Deployment models → How your data is handled The data flow and controls your IT team will want to review. Security & sovereignty → What we build on it See examples of agents handling documents and work across systems. What we build →

A useful first conversation

Where does the work get stuck?

Bring the workflow people actually follow, including the workarounds. We will trace where it gets stuck. Then we will agree on the approvals and one result to measure after launch.

Map a workflow with our engineers

Talk directly with the engineers who build the agent.

Discuss a Workflow