Your customers want AI inside your product.
Not bolted to the side.
An agent layer should not require building an AI infrastructure company. Runtype gives SaaS, marketplaces, and vertical software teams an AI product runtime where agents know customer data, respect permissions, and act through your APIs.
The agent layer is table stakes. The runtime isn’t your business.
Customers are asking when your product gets agents, and they mean agents that understand their data, respect their roles, and act through your APIs. Building that in-house means orchestration, credential isolation, per-tenant capabilities, evals, and observability at scale. None of it differentiates your product. All of it can sink your roadmap.
Per-tenant tools and permissions
Credentials kept out of model context
Native embedding, not an iframe hack
Observability across every tenant
Model routing you can change silently
API and MCP surfaces for integrators
Three ways platform AI initiatives stall.
Most platforms have already tried at least one of these. The pattern is the same: the easy version disappoints, and the proper version is quarters of infrastructure work.
The internal prototype
A hack-week agent that demos beautifully on test data. Multi-tenant reality (data boundaries, permissions, scale) is exactly the part the prototype skipped.
The bolted-on chatbot
A generic assistant in the corner of the screen. It can’t act through your APIs or respect roles, and customers notice. Usage flatlines after week one.
The roadmap collision
Doing it properly in-house is quarters of platform work. Customer expectations move on model-release time. The gap between the two is where renewals and deals stall.
Build the feature, not the infrastructure company.
The in-house version of an agent layer is a second product with its own roadmap. The runtime version is a feature you ship this quarter.
An agent layer that behaves like part of your platform.
The hard requirements of embedded, multi-tenant AI map directly onto runtime primitives you don’t have to build.
Agents that feel native to your product
API + MCP surfaces
Dispatch agents from your backend over HTTP and SSE, embed a themeable chat surface in your UI, and expose MCP tools so your customers’ own agents can work with your platform.
Different tenants, different capabilities
Runtime tool composition
Define which tools an agent gets at dispatch time, based on tenant, plan, or role. One agent definition, per-customer behavior, and no forked logic.
Customer credentials never enter model context
Protected parameters
Tenant credentials are injected at execution time and never enter model context. The agent calls the customer’s systems without ever seeing the secret.
State that belongs to the tenant
Records
Memory, context, and artifacts scoped per customer. Each tenant’s agent knows their history, and only theirs.
Operate it like a real platform feature
Evals + logs
Regression-test agent behavior before rollout and trace any tenant’s execution when support escalates. Observability is built in, not a follow-up project.
Swap models without breaking customers
Model routing
Multi-provider routing behind one interface. Change models per step or per workload, verify with evals, and ship it without a customer-visible migration.
Agent features your customers are already asking for.
Each of these ships as a capability of your product, running on a runtime you don’t have to operate.
Embedded support and ops agent
An in-product agent that answers from the customer’s own data and acts through your APIs: creating, updating, and resolving instead of deflecting.
AI workflow features
Let customers trigger multi-step AI workflows from inside your product: enrichment, document generation, and classification, with your branding and their permissions.
Integration copilot
An agent that walks customers through connecting, configuring, and debugging integrations: the onboarding work that currently burns your solutions team.
Common questions
Can we embed this in our own UI?
Yes. Use the themeable chat widget via script tag or React component, or skip the widget entirely and drive executions through the HTTP and SSE API from your own frontend.
How does multi-tenancy actually work?
Capabilities are composed per dispatch: you decide which tools, context, and records each tenant’s request gets. Credentials are scoped and injected at execution time, and every tenant’s executions are logged separately.
Can our customers’ agents use our platform?
Yes. Expose your capabilities as MCP tools, and customers’ agents in Claude, IDEs, and internal tooling can operate your platform directly, with your authentication in front.
What if we already started building in-house?
Keep what differentiates you: your product logic and your APIs. Runtype replaces the undifferentiated layer underneath, including orchestration, surfaces, credential isolation, evals, and logs. Your existing APIs become tools.