Business Operations

The continuous process by which a business runs and supervises the work itself — through human and AI collaboration. Where Business Evolution is the design-time loop that defines and changes how the business works, Business Operations is the run-time loop that exercises those definitions: agents do the work autonomously, surface what they can’t decide, and humans supervise the boundary. It is Business Evolution’s peer, not its child.

Business Operations is the continuous process through which a business executes its work, monitors that execution, and decides where a human must step in — moving work from human hands to AI hands over time, while keeping a human in the loop wherever judgment is scarce.

Two Loops, One Rhythm

p6k runs on two loops, not one. They are peers — different subjects, different cadences, different tables — joined at two seams into a single figure-eight:

            BUSINESS EVOLUTION  (design-time — changes the system)
   Conversation → Knowledge → Plan → Spec → Generate → Publish
        ▲                                                  │
        │  seam 2: STRUCTURAL TUNE          seam 1: HAND OFF │
        │  (a runtime adjustment too big                    │
        │   for runtime → a new Evolution turn)   running   │
        │                                          system   ▼
                         BUSINESS OPERATIONS  (run-time — runs the system)

• Business Evolution changes the system. Every turn writes a definition — s_spec, s_plan, s_playbook, s_knowledge. It is episodic: it terminates each cycle at Publish. You don’t live in it.
• Business Operations runs the work. Most turns change no definitions at all — they write operational records: s_work, s_ai_session, s_ai_request, s_workflow_run. It is continuous: it never terminates. You live in it daily.

The two are coupled at exactly two seams:

• Seam 1 — Hand off (Evolution → Operations). Publish/Run deposits a running system; the Operations Loop picks it up. Publish is a transition, not a place — the moment a definition becomes something agents can execute. This is the seam that makes the Operations Loop feel like it lives “inside” Business Evolution’s Run stage. It doesn’t — it begins where that stage ends.
• Seam 2 — Structural tune (Operations → Evolution). A small adjustment stays inside the Operations Loop. But when an adjustment requires a capability change — the agent needs to do something it was never defined to do — it is too big for runtime and escalates up into a new Evolution turn. (See The Tune Threshold.)

This is a design-time / run-time split: Business Evolution produces the running system; Business Operations runs it. The seams are data handoffs, not handoff documents — the same root-object backbone threads both loops.

Three Altitudes

Business Operations is the middle of three nested loops. Naming all three is what keeps the design honest about what is a peer and what is genuinely nested:

The Agent Task Loop is the agentic loop (internal) — plan, act, verify, iterate — that runs inside a single s_ai_session. It is genuinely nested: fully contained, it terminates, and it returns a result to its still-running parent. That is what real nesting looks like, and Business Operations does not have that shape relative to Business Evolution — which is exactly why Business Operations is a peer, not a sub-stage.

Business Operations is therefore not an execution loop. The execution already happens one altitude down, inside each agent. Business Operations is a supervision and delegation loop: the human is not doing plan/act/verify, they are watching agents do it and deciding where to intervene.

Business Operations Comprises Two Peer Loops

“Run the work” is two different jobs, and they are peers of each other — not one loop with two modes:

• The Fulfillment Loop — doing the requested work. Tickets, reconciliations, proposals, emails. Work flows in, gets done, occasionally needs a human. (Matt, Mia, Tier-1 support.)
• The Monitoring Loop — watching the running system and fixing it. Logs, SLAs, metrics, anomalies. Agents observe continuously and surface what’s off. (A support manager’s SLA monitor; a p6k operational dev’s log and security watchers.)

They are peers — different triggers (delegated work vs. a continuous signal), different “done” (an outcome vs. a clean board) — but they share one membrane and both escalate the same way. The Monitoring Loop watches the output of the Fulfillment Loop (among other things) and catches what Fulfillment’s own checkpoints missed; a detected issue can itself become a corrective work item that the Fulfillment Loop then runs. The whole run-time half is itself a small figure-eight, fractal with the larger one.

A guardrail against sprawl. These are conceptual loops. The product surfaces them as one Operator home, not four diagrams a user must reconcile. The two-loop structure tells us what the home must distinguish (fulfillment work vs. monitoring) — it is not a mandate to ship two separate screens.

The Fulfillment Loop

The Monitoring Loop

The Membrane: How Work Crosses Back

An agent is autonomous by default. It runs through an s_ai_session on its own until it reaches something outside its competence (it doesn’t know how) or its authority (it isn’t allowed to decide) — and at that edge it stops, raises an s_ai_request, and waits for a human. The needs-attention surface is that membrane: the place where agent work crosses back to a person.

There are two flavors of crossing, both already modeled:

• Unblock-me — the agent is suspended; the human’s answer resumes the loop. (s_ai_session in awaiting_input / awaiting_review.)
• Do-this-for-me — the agent delegated a human-only task and kept autopiloting. (An s_ai_request raised by a non-suspending tool.)

The direction of that crossing is the thing to hold onto. In ordinary automation a human watches a machine and steps in to stop it. Here it is inverted: the agent works on its own and summons the human only when it hits the edge of what it can do or decide. Escalation flows upward — autonomous-by-default labor reaching up to scarce human judgment, exactly when it’s needed and not before. That inversion is only possible because the agent can reason about its own competence, and it’s the shape the whole Operator home is organized around.

The Trust Gradient

The operator’s actual daily job is not doing the work and not even verifying all of it — it is deciding what to verify. Verification is risk-weighted and decays as competence is proven: early on you check everything (low trust); as an agent earns it, you check by sampling. This is the engine of bottom-up adoption — work moves from the human’s desk to the agent’s desk one proven step at a time.

The trust gradient is the governor on the membrane: it sets how much autonomy an agent gets and how much a human samples its output. The work that moves across first is the repetitive, low-judgment work; what stays longest is the work where being wrong is expensive. Tuning that gradient — granting more autonomy here, holding a checkpoint there — is the operator’s core lever, and it’s why the agent’s desk is a trust dashboard, not a log: the summary of “what the agents handled for you this week” is the evidence that justifies delegating more. Take it away and the loop stalls, because no one moves a second piece of work across a boundary they can’t see paying off.

The Tune Threshold

Seam 2 is the most failure-prone part of the model, so the threshold must be explicit:

• Small tune — stays in the Operations Loop. An in-place adjustment by the person running the work: bump an autonomy level, add a guardrail, answer a checkpoint a better way. No definition changes; no s_spec is touched.
• Structural change — escalates to Business Evolution. A change to what the agent is — a new capability, a new integration, a changed contract. Mia’s January flood of unrecognized Medicare policies isn’t something to re-answer fifty times; it’s a signal to teach the agent to create them from Salesforce. That crosses seam 2 into a new Evolution turn.

The seam must be operator-initiated and low-friction, or the peer model recreates a wall between the people who run the work and the people who change the system — the same wall p6k’s whole premise is meant to dissolve. When the same checkpoint is raised again and again, the membrane is telling you the system itself is wrong. The operator must be able to trigger an Evolution turn from inside the Operator home, not file a ticket over a wall to “engineering.”

The Desk Metaphor

The Operator home renders the loop as motion across a membrane, not a flat worklist. Three zones:

┌──────────────┐   ┌──────────────────┐   ┌──────────────────┐
│   MY DESK    │ → │ NEEDS ATTENTION  │ ← │   AGENT DESK     │
│ work I still │   │  (the membrane)  │   │ roster + what    │
│ do myself —  │   │  unblock-me /    │   │ agents are doing │
│ delegation   │   │  do-this-for-me  │   │ + the trust      │
│ candidates   │   │  checkpoints     │   │   dashboard      │
└──────────────┘   └──────────────────┘   └──────────────────┘
        └──────────── delegate ───────────────▶
        ◀──────────── escalate ────────────────┘
                         ▲ recurring escalation → Evolution (seam 2)

• My desk is the delegation backlog — work the human is still doing themselves. This is the zone that makes the Operator home more than a ticket queue: it nudges work across the membrane. Without it, there is no delegation gradient, only an inbox.
• Needs attention is the membrane — the only zone already well-built today. It must read as a crossing (where agent work comes back to a person), not a separate list.
• The agent desk is the roster plus the trust dashboard. It answers “what did the agents save me?” — the question that earns the next delegation.

Personas

The same Operations Loop, different operators — and which loop and stage they live in tells you what their home must foreground.

Tier-1 Support — the Fulfillment Loop, at Checkpoint

A support rep opens the Operator home to a queue of agent-drafted replies and tickets the agent couldn’t close alone. They live at Checkpoint with low initial trust: reviewing nearly everything, watching the trust dashboard climb until they’re sampling instead of checking. Their home is needs-attention-forward.

Support Manager — the Monitoring Loop, at Monitor → Tune

A manager supervises lower-level agents: one reading the shared inbox, one watching SLAs and escalations. They live in the Monitoring Loop, watching the board stay clean and tuning autonomy — and, when escalation patterns repeat, crossing seam 2 to evolve an agent’s capability. Eventually, team metrics.

p6k Operational Developer — the Monitoring Loop, at Monitor

Operational agents watch logs, performance, security, and anomalies — scheduled operators whose checkpoints are “I found something off, look.” This persona lives almost entirely in Monitor → Detect, and is the proof that the Monitoring Loop is a peer in its own right, not a footnote to fulfillment.

Matt — a Fulfillment-Loop delegator, at Delegate

Matt’s book is a pile of delegation candidates sitting on my desk: the weekly US Bank deposit pull-and-dedupe, routing RFPs to his GA, birthday emails via Levitate, intake of carrier renewal data. He lives at Delegate, moving recurring work across one piece at a time so he can focus on relationships — the same desk-to-desk motion he already runs by hand when he transitions service groups to Hannah.

Mia — the whole Fulfillment Loop, end to end

Mia is the cleanest illustration of the full loop. Her ~81 carrier maps are automations already configured (Delegate done). Pulling and normalizing statements is Run. The red rows — unrecognized policies she can’t link without identifying the owning agent — are Checkpoint, work crossing back to a human. Her purple-marking is the human verify. And the seasonal flood of red rows when Ben writes new Medicare business is the textbook seam-2 signal: a recurring checkpoint that should become a capability, not a chore.

Relationship to Existing Concepts

Business Operations is the narrative catching up to infrastructure that mostly already exists:

• agent-operations (internal) is the implementation: the three-level agent model (s_ai_agent_template → s_ai_agent → s_ai_session), s_ai_request extends s_work, roster/placement/status, and the two-flavor inbox. Business Operations is the vision that frames why that infrastructure has the shape it does.
• OperatorHome.vue is today’s render — a dashboard. This doc is the argument for evolving it toward a loop surface: the three-zone desk membrane above.
• business-evolution is the design-time peer. The two docs together are the platform’s complete rhythm; read either alone and you only see half the figure-eight.
• Workflows and Actions (internal) provide the Monitoring Loop’s substrate — trigger_type: scheduled operators, the agent action, and request-approval writing s_ai_request rows.
• The agentic loop (agentic-loop (internal)) is the innermost altitude — the Agent Task Loop that runs inside every Run step.

The architecture already votes peer. Two top-level surfaces — Evolve home and Operator home — ship today as equals. This document is the conceptual spine that makes that split deliberate rather than incidental.

Proof: We’re Already Living It

The p6k team already runs the Operations Loop by hand. The build loop is fulfillment: work is delegated to agents, they run autonomously, they surface what needs a human (the needs_code_review gate is an agent crossing the membrane), and trust is sampled rather than total. Watching agents work the backlog is the Operator home, rendered as a terminal and a dashboard. As with Business Evolution, the process is working before the platform exists to host it — which is the strongest signal the idea is real.