An AI Agent Is an Employee, Not a Prompt: 6 Essentials
An AI agent you intend to rely on needs six things declared before it starts work: a capability manifest, an integration and account scope, a permission and approval scope, a trigger, a memory scope, and an evaluator. None of them can be left implied by the prompt. A prompt describes intent; these six describe employment. The difference matters because a prompt is judged on whether its output reads well, while an employee is judged on whether the organization can rely on it next quarter — and reliability comes from declarations made up front, not from instructions written well.
The permission and integration scopes above are the security surface of an agent; agent security and permissions works through what that means when something goes wrong.
What follows is an operator's checklist: what each item is, and what breaks without it.
1. A capability manifest
A capability manifest states what the agent is allowed to do, declared explicitly and stored where others can read it. Not what it can technically attempt — what it is sanctioned to perform. Send external email. Modify production configuration. Move money. Each capability named, each one a deliberate grant.
What breaks without it. Capability becomes an emergent property of whatever tools happen to be wired in. Nobody knows the agent's surface area, so nobody can reason about its blast radius. Review degrades into archaeology: reading the code to work out what the thing could do. And an undeclared surface expands silently — a tool attached during a debugging session is never removed.
The manifest is also the only honest basis for delegation: you cannot hand an agent a role without stating, in a sentence a non-engineer understands, what it may do. That is what separates an installed worker from an experiment, a distinction developed in what an AI workforce actually is.
2. Integration and account scope
Capability answers what. Integration scope answers where, and as whom: which external systems the agent reaches, which accounts within them, and what access it holds in each. It reads from the analytics workspace but writes only to staging. It authenticates as its own service identity, not as the engineer who set it up.
What breaks without it. Credential inheritance, the most consequential failure in early deployments. An agent quietly holds a person's full access because that was the fastest way to make it work. Every action it takes is attributed to that person, revocation becomes all-or-nothing, and attribution becomes impossible — attribution being the foundation everything else rests on. Scoped identity makes an agent an actor rather than a script under borrowed authority — a precondition for governance, not a refinement of it.
3. Permission and approval scope
This is the item most often confused with the other two. Capability says the agent may issue refunds. Approval scope says it may issue them unsupervised below a threshold, must route them to a named person above it, and must never issue them in a specific category. Written properly, it contains an impact classification, a rule for each level, and a named resolver for anything that stops.
What breaks without it. Two failure modes, opposite in appearance, identical in cause. Either everything requires approval, and the agent is a slower tool with the bottleneck restored. Or nothing does, and you discover the boundary by having crossed it. Both come from leaving the boundary undeclared and hoping judgement fills the gap.
The useful model is that human-in-the-loop should be a data structure, not a policy document: a document describes intent to a reader, a data structure enforces it at runtime on every decision. Writing these boundaries across a fleet is the subject of how to govern an AI workforce.
4. A trigger
A trigger is what wakes the agent: a cadence, an event, or a threshold. Every weekday at eight. When a deployment fails. When a metric crosses a bound. Without one, an agent has a role it never performs.
What breaks without it. The agent reverts to a tool. Someone has to remember it exists and go start it, so its output tracks that person's attention rather than the occurrence of the work. This is the most common reason agent deployments quietly fail: the capability was real, the trigger was a human intention, and human intentions do not fire reliably.
Triggers also make behavior legible. When agents wake on declared conditions, agent presence becomes a read of what is happening across the operation rather than a status widget.
5. Memory scope
Memory scope declares what the agent reads from shared organizational memory, what it writes back, and what stays private: which conclusions are promoted to the shared layer, which observations remain local, and what the agent may see about work it did not perform.
What breaks without it. Two things, in sequence. First, agents repeat each other's mistakes: one learns a customer's constraint on Tuesday and a second violates it on Wednesday, because there was nowhere for the first to put what it learned. Second, and less discussed, undeclared memory means agents over-share. Context that should have stayed local propagates into shared state and contaminates the reasoning of everything that reads it. An unbounded memory is not a richer memory; it is a faster path to confident errors.
Being honest about this layer
Shared organizational memory that reliably propagates what one agent learns to every other agent does not exist as a solved product — not at FlashyOS, and not, as far as we can see, anywhere else. It is the open gap in the category, and the current answers are partial: retrieval over documents, per-agent context windows, knowledge bases that drift.
Flashy Mind is our approach to this layer, and it is in design — designed and prototyped, ahead of build. It does not ship today, and we will not imply that it does. The reason to declare memory scope now, before the layer exists, is that agents deployed without one will need it retrofitted, and retrofitting boundaries onto systems that already share everything is far harder than declaring them at the start. The groundwork is in organizational memory for AI agents.
6. An evaluator
An evaluator defines how performance is measured: what a good outcome looks like, how it is scored, how often, and what happens when the score moves. It is the least glamorous item here and the one that decides whether the agent improves after month one.
What breaks without it. Behavior freezes at onboarding. The agent performs a year later exactly as it did on the day it was configured, because nothing measures drift and nothing feeds back. Worse, degradation is invisible: nobody notices six weeks of subtly poorer work, because the only signal was a vague sense that something felt off.
An evaluator need not be sophisticated, only specified, applied consistently, and reviewed on a cadence by someone accountable for the outcome. Improving against those signals is AI agent optimization.
The checklist, compressed
- Capability manifest — what it may do. Missing: undefined blast radius.
- Integration and account scope — which systems, as whom. Missing: inherited credentials.
- Permission and approval scope — unsupervised versus escalated. Missing: bottleneck or breach.
- Trigger — cadence, event, or threshold. Missing: a role nobody performs.
- Memory scope — reads, writes, what stays private. Missing: repeated mistakes, contaminated context.
- Evaluator — how performance is measured. Missing: behavior frozen at onboarding.
Write these six down before the first run. It takes about an hour per agent and is the difference between a fleet you manage and a fleet you discover. Agents whose scope is undeclared cannot be coordinated, whatever layer you put above them.
What is enforced in production today
Four of the six are live in FlashyOS as data structures rather than conventions. Capabilities are declared per agent and stored per organization. Approval scope is real: decisions carry an impact level from low to critical and a status of auto-approved, pending, approved, or rejected, with a named human resolver, and organizations set auto-accept policies declaring by category what their agents may do without asking. Lifecycle is visible through live agent presence — active, building, reviewing, incident, idle, offline — with current task and progress, and every session writes an append-only event log of actions, commits, errors, and task lifecycle. Cross-organization initiatives require approval from every participating organization before becoming active; one rejection archives the proposal.
Any organization's agent activity can be inspected on the public Live HQ without a login. Memory scope is the item still ahead of us and ahead of the industry.
If you are working through this checklist for a fleet that reaches beyond your own organization, that path runs through Mesh.