Bud Studio
The consumption layer of the Bud stack — a desktop app that gives every employee a personal AI agent, connected to the tools the organisation has approved, learning from their work, and coordinating with other agents to get things done. Every action governed by SENTRY.
Enterprise AI, in everyone's hands.
Studio is where the AI an organisation builds actually reaches the people doing the work. Instead of scattered chatbots and shadow AI, every employee gets one governed agent — running on the organisation's own models, connectors, and permissions, on their own machine.
Layer 07 of the Bud stack.
Where employees create agents — and consume the platform. Everything below Studio provisions and governs; Studio is where people use it.
Consumes everything below — models served by AI Foundry, tools published by MCP Foundry, on hardware the lower layers already reach. Nothing is configured twice.
Governed by SENTRY — every request, connector call, and agent-to-agent exchange passes the same policy plane as the rest of the platform.
Everything an assistant should do. And a network.
All eight capabilities, expanded to the specifics an evaluator needs — what the agent does, who can use it, and how the network stays governed.
Architecture & components.
One agent per employee, two roles per agent, and two pipelines that make the product what it is: the agent-to-agent request path and the canvas-to-skill pipeline.
The agent-to-agent request path
The Inbox is the observability layer of the network — every agent-to-agent exchange is a visible, inspectable thread, and you can respond inside one directly.
The canvas-to-skill pipeline
Only repeated tasks become skills. One-off requests are ignored — the library stays a set of procedures you actually use.
Foundry → Studio inheritance
| Set in Bud AI Foundry | What Studio inherits |
|---|---|
| Models | Admins publish model deployments; users pick from what's published, chosen from chat. |
| Connectors | Enabled and configured centrally; authorised per user in Studio without sharing credentials. |
| Guardrails | Set on model deployments — including custom guardrails — and applied to every Studio request. |
| Permissions | Which tools each user and agent can access, including agent-to-agent behaviour. |
Component inventory
| Component | Surface | Role |
|---|---|---|
| Personal agent | chat | One per employee — independent memory, context, and personality; the interface to everything else. |
| Memory | agent | Learns from feedback in normal conversation; no settings screen. |
| Agent network | org-wide | Agent-to-agent requests across employees and purpose-built agents, permission-checked. |
| Inbox | observability | Email-style threads of agent conversations — inspect any exchange, respond directly. |
| Connector auth | per user | Sign-in flow per tool, per user; raw credentials never shared with the agent. |
| Scheduler | chat | One-off, interval, and recurring tasks created conversationally. |
| Canvas | workflow | Draws repeated procedures as visible, editable workflows. |
| Skills | agent | Auto-generated procedures from repeated workflows; evolve as the process changes. |
| Generated interface | chat | Visual responses — charts and views rendered from the request where content supports it. |
A desktop app, by design.
Studio is desktop-first so it can access the local file system and carry out tasks on the user's machine — something a web app cannot do.
| Platform | Form | Notes |
|---|---|---|
| macOS | native desktop app | Local file-system access; tasks on the user's machine. |
| Windows | native desktop app | Local file-system access; tasks on the user's machine. |
| Linux | native desktop app | Local file-system access; tasks on the user's machine. |
| Web | — | Not currently offered — desktop-first is a deliberate design decision. |
Desktop platforms
Native apps across the three desktop operating systems your workforce runs.
Why desktop-first
Local file-system access lets the agent work with the files and applications on the machine — drafting from documents, filing outputs, carrying out tasks a browser sandbox cannot reach.
Backed by your platform
Studio connects to your organisation's Bud deployment and consumes only what it provisions — the models, connectors, and guardrails stay wherever the platform runs.
What's structural, and what ships with numbers.
House rule: numbers ship measured, not asserted. Studio is a consumption product — most of its claims are structural properties you can verify in the product today. Its performance metrics land here with methodology once measured on production deployments.
True by design — verifiable in the product
- Every connector is authorised per user with that user's own account; raw credentials are never shared with the agent.
- Every request, connector call, and agent-to-agent exchange is subject to the permissions set in Foundry and governed by SENTRY.
- Every agent-to-agent exchange is observable — a thread in the Inbox showing who asked whom and what was shared.
- Skills are generated only from repeated tasks, and update when the user changes the process.
- Desktop apps ship for macOS, Windows, and Linux with local file-system access.
Ships with numbers, later
- Routine-work time reclaimed per employee — instrumented across pilot deployments.
- Agent-to-agent request volume and resolution — measured from Inbox telemetry.
- Skill generation and reuse rates — how much repeated work converts, and how often skills run.
- Adoption and coverage across a rollout — daily active agents per seat.
Each of these lands with the workload, the deployment, and the measurement method attached — the same standard as every other Bud proof section.
Three things comparable assistants don't do.
Enterprise assistants exist — standalone ones. Studio's differentiators are the network, the permission model, and the skills that write themselves.
| Alternative category | What it gives you | What Studio adds |
|---|---|---|
| Copilot-style assistants | A standalone assistant per seat | An agent network — each user's agent reaches other agents to retrieve information and complete tasks, subject to permissions |
| Consumer chatbots | General-purpose chat, no enterprise controls | Governed consumption — models, guardrails, and permissions inherited from Foundry; zero shadow AI |
| Workflow builders | Automation you author by hand | Auto-evolving skills — repeated workflows become skills automatically and update as the process changes |
| Browser-based AI tools | A web-only surface | Desktop-native — local file-system access and tasks on the user's machine |
Built for how enterprises actually work.
Studio is the layer a whole workforce touches — deployed by the enterprise, shipped by the OEM, or offered by the CSP.
An agent for every employee
Deploy assistants across the workforce. Alongside their personal agent, employees use purpose-built agents the organisation publishes — request leave, retrieve a salary slip, query finance.
Pre-installed on your systems
Ship Studio on the machines you sell, so the assistant is available to users out of the box — backed by the Bud platform underneath.
A consumption-layer product
Offer a co-working assistant as a product on top of your AI infrastructure — the layer customers' employees actually touch, not another slice of compute.
The platform argument, in full.
This brief is the product reference. For why consumption belongs on a governed platform — and what the rest of the stack provides — read the platform whitepaper, or see Studio in a working session.
Platform White Paper
The Enterprise AI Management Platform
Where governed consumption comes from
The platform-level argument — why the layer employees touch must inherit the governance, serving, and cost control of the layers beneath it, not bypass them.
Read the whitepaperBack to overview
Bud Studio
Enterprise AI, in everyone's hands
Return to the high-level product page — the one-agent-two-roles idea and the overview of the consumption layer.
Back to the product pagePut your data on it.
The fastest way to see what an integrated AI operating system does for your enterprise is a proof-of-concept on your infrastructure, with your data.