What your customers get
An AI agent on a small appliance in their office. Their staff talks to it in plain language: "Which apprentices have three absences this month?" "Draft a follow-up note for the case manager." "Match these students to the new job opening."
The agent reads and acts on their data through your existing API — same roles, same permissions, same audit trail. It's not a superuser. It's a new staff member that follows the same rules as everyone else.
Your customer's data stays on their hardware. The agent, the keys, the conversation history — all on a device they own. You don't host the agent. You don't see the prompts. You just ship the API surface.
the qbit.me app — tray open over your workspace
The workspace. Every note, session, and project one click away.
tray — every note, session and project, together
Trays. Group your notes, sessions, and projects into one workspace you can reach in a click.
notes → sessions → projects
Notes → Sessions → Projects. Compose ideas as notes, convert one into a session the moment it's ready, and drive execution in projects.
active sessions
Active sessions. One dialog lists every live session across all your trays — click any row to jump back in.
Proof: the EDDR case study
EDDR Student Management System is the first agent-native trade school SIS — 74 MCP tools, 239 students, 20 active cohorts, running on the school's own server. Case-manager triage dropped 6x. Job matching went from 2–3 staff to 1. Read the full case study →
What you do
One thing: add a thin proxy to your existing API. It takes your existing REST endpoints and exposes them as tools the agent can call. Roughly 200 lines of code. Your validation, audit logging, and side-effects all run unchanged — the proxy just forwards the call.
You don't rewrite controllers. You don't change your auth model. You don't host anything new. The proxy is additive — your existing REST API keeps working exactly as before.
How the agent respects roles
The agent uses an API key that's scoped to a role. A registrar can create students. A case manager can acknowledge shortfalls. An instructor can post attendance. The agent only reaches what the role permits — your existing permission system enforces it, not us.
Same roles, same permissions, same audit trail.
| What the agent does |
Example |
| Reads and summarizes |
"Which apprentices have 3+ absences this month?" |
| Surfaces candidates |
"These 5 students match the new job opening." |
| Drafts for human approval |
Drafts follow-up notes for the case manager to review |
| Acts after confirmation |
Posts attendance after the instructor confirms |
| Runs autonomously on routine cycles |
Archives completed cohorts at term end |
How to get there
Two paths to the same outcome: your product becomes agent-native, and your customers run the agent on hardware they own — paying per call, not per month.
- Self-serve ($0 integration fee) — use the integrator guide and reference implementation. Your customers pay per call through their agent.
- Guided ($5–15K one-time) — we audit your API, build the proxy, test, deploy, and train your team in 1–2 weeks.
- Deep ($15–35K one-time) — everything in Guided plus custom workflow design, multi-customer rollout, and a co-branded case study.
Full inclusions and pricing live on the Pricing page. The integration fee is one-time; your customers pay per call after that. No monthly agent plans, no tier complexity.
The integrator guide covers the MCP endpoint, authentication, tool discovery, and key safety. The reference implementation is coming soon.
Why this works
- You don't rewrite anything. The proxy forwards to your existing controllers. Your validation, audit log, and side-effects run unchanged.
- Your customer owns the runtime. The agent lives on their hardware. You don't host it, you don't see the prompts, you don't store the conversation.
- Your permissions are the boundary. The agent's API key is role-scoped. It only reaches what the role allows.
- If you have a REST API, you're already agent-native. The proxy is additive, not a rewrite.
Open source, by design
The device runtime your customers run is open source — Apache-2.0. The daemon that executes on their hardware, the capability contracts it codes against, the tunnel, BLE provisioning, the IoT adapters — code you can read, build, and fork. Browse the source →
The moat stays private. Attested context, settlement, and the official distribution build are not in the public tree. Private capabilities reach the open core only through qbit-me-runtime-api's capability traits, which fail closed when the private implementations aren't linked — the open build runs with those capabilities unavailable rather than misbehaving.
The open device runtime, and the private layer it codes against.
Sandboxed apps and toolsets run inside qbit-me-wasm-runtime — part of the same open layer, so the confinement and metering you audit is exactly the confinement and metering that runs.
First step
A 1-2 hour call. We review your API, map endpoints to agent tools, identify the permission model, and send you a fixed-quote proposal. No commitment.
Book a scoping call
See pricing
Prefer to self-serve? Read the integrator guide for the MCP endpoint, authentication, and tool discovery. Get a qbit agent to start building.
Looking for an agent for yourself, not your product? Visit our consumer site.