§01 · The five layers

Five words, kept strict

Most confusion about agent platforms comes from one flattened noun: “tool.” Bizer keeps five distinct terms, because “Google Workspace,” “Gmail,” “send an email,” “your OAuth grant,” and “the inbox-triage playbook” are five different kinds of thing. The first three form a strict hierarchy; a connection activates an app; a skill sits off to the side.

App › Tool › Operation is a strict hierarchy. Connection activates an app. Skill grants nothing.

§02 · The hierarchy, concretely

One connection, an entire suite

The layers aren’t academic; the code already has them. A single Google Workspace app, reached through one "google" connection, currently exposes 23 operations grouped into nine tools. Calling all of that “a tool” would flatten three real levels into one.

Not every app is a suite. WordPress is essentially a single-tool app, where the middle tier is thin. The hierarchy still holds.

§03 · App, Tool & Operation

The three rungs of the ladder

App: the connected product

An app is a whole product an owner connects: Google Workspace, WordPress, Stripe, Twilio, or Bizer’s own always-available built-ins. You connect Google Workspace, not “Gmail” and “Calendar” separately. In code an app is its connection provider id.

Tool: a capability inside an app

A tool is one distinct capability within an app: Gmail, Calendar, and Drive are tools inside Google Workspace. It’s the level a person names: “check my email” (Gmail) versus “what’s on my calendar” (Calendar). Today the tool tier is a grouping convention over operations; access is never granted or denied here.

Operation: a single callable action

An operation is the smallest unit: one action Miles can invoke, like gmail_send. It’s the level the code has always named. Each is a ToolEntry declaring its schema, the app it belongs to, the scopes it needs, and whether it must be confirmed before firing.

export interface ToolEntry {
  declaration: FunctionDeclaration; // the operation's name + schema Miles sees
  connection: string;       // which app it belongs to ("google"), "" = built-in
  scopes: string[];        // OAuth/credential scopes the operation requires
  run: (ctx, args) => Promise<unknown>;
  requiresApproval?: boolean; // write action → owner must confirm before it fires
}

§04 · Connection

The layer that grants access

A connection is the wiring plus the credentials that make an app usable, and it grants the whole app at once. Connect Google Workspace and every Gmail, Calendar, and Drive operation becomes callable, bounded only by the OAuth scopes you granted. Connections come in four shapes: MCP over HTTP, OAuth, an API key, or “native” for Bizer’s always-available built-ins.

This is the crux of the whole architecture. The set of operations Miles may call is derived purely from which apps are connected, plus the built-ins. Skills are never consulted:

export function operationsForConnections(connected: Set<string>): string[] {
  return Object.entries(TOOL_REGISTRY)
    .filter(([, entry]) => entry.connection === "" || connected.has(entry.connection))
    .map(([name]) => name);
}

Read the filter: an operation is available if it’s a built-in or its app is connected. Skills never appear in this function, because they have no say in access.

§05 · Skill

Portable know-how, off to the side

A skill is a set of portable instructions telling Miles how to accomplish something with whatever it can reach. When enabled and relevant, its instructions body is appended to Miles’s system prompt. That is the entire mechanism: a skill changes what Miles knows how to do, never what he can do. It sits off to the side of the App › Tool › Operation stack: guidance, not a rung.

Because a skill is instructions-only, several tempting patterns are simply wrong, and each is a signal that the real intent is an app or connection change:

• Listing operation IDs to “unlock” them: a skill has no say in access; requirements.tools is deprecated and stays [].
• Building a “read-only Gmail” skill: scope belongs on the connection (connect the app with read-only OAuth scopes), not the skill.
• Assuming an ability exists only when the skill is enabled: the connection grants it either way.
• Hard-coding Bizer operation IDs into the prose: it kills the portability that lets a skill run on any capable agent.

§06 · A request, end to end

Watch the layers separate

The owner has connected the Google Workspace app and enabled the “inbox triage” skill. Access is computed from the connection: every Google operation, plus built-ins. The skill contributes nothing to that list; it only shapes how Miles triages. Reads (gmail_search) run immediately; the write (gmail_send) requires the owner’s tap-approval before anything leaves the outbox.

The proof is in what happens when you flip each switch independently:

§07 · Where safety lives

Not in a skill, never in a skill

Access is broad by design, so safety lives in the connection and execution layers, where it can’t be bypassed by toggling guidance:

• Connection scope. OAuth scopes and stored credentials define the ceiling. Want read-only? Connect the app with read-only scopes.
• Per-operation approval. Write and side-effecting operations carry requiresApproval; they queue a pendingApproval and run only after the owner taps approve. An action confirmation, not an access gate.
• Verified vs. unverified. Catalog, OAuth, and Pipedream apps are verified. An owner-supplied ad-hoc MCP URL is unverified: Miles treats its descriptions and results as untrusted content and never leaks private data to it.
• Secrets at rest. Encrypted with TOKEN_ENC_KEY, default-denied by firestore.rules, readable only by the platform’s Cloud Functions.

None of these knobs is a skill. A skill can’t widen a scope, can’t skip an approval, and can’t reach an unconnected app.

§08 · Why the model holds

One rule, cleanly enforced

The architecture is deliberately generic. Adding a capability is a connection and a catalog entry, never bespoke agent code. Naming it precisely (with App › Tool › Operation, Connection as the grant, and Skill as the guidance) keeps every part of the system, and everyone building on it, pointed at the same truth: