Workloop Spec

The complete normative text follows. This is a draft for comments: open an issue in the repository or reply to the author.

Summary

An agentic workloop is a system of two or more agentic loops that interact with each other through explicit channels. When all participants are under the same policy authority (the organization that created them), the workloop is governed, and this specification requires every inter-loop interaction and externally effecting action to pass through a deterministic gate that enforces that authority's policies and business rules. When the graph crosses the authority boundary, the workloop is open and defensive rules apply. This document defines the terms, the invariant ("freedom inside the loop, determinism at the seam"), the corollaries, operational requirements, and conformance criteria.

Abstract (EN)

An agentic workloop is a system of two or more agentic loops that interact through explicit channels. When every participant sits under one policy authority (the organization that created them), the workloop is governed: no inter-loop interaction and no externally effecting action may occur without passing through a deterministic gate that enforces that authority's policies and business rules. When the graph crosses the authority boundary, the workloop is open and defensive rules apply. This specification defines the terms, the invariant ("freedom inside the loop, determinism at the seam"), corollaries, operational requirements and conformance criteria.

1. Motivation

Agentic loops, processes in which a model decides actions and uses tools until it stops, are no longer isolated units. In real operations, a support loop writes to a CRM that another loop reads; a media loop publishes what another loop comments on; one loop asks another to execute what it cannot execute itself. This is where conformance is lost. Inside a loop, prompts, skills, and instructions are non-deterministic policy: the model may or may not obey. The organization needs a place where policy is enforced by code, not requested by a prompt. That place is the seam: between loops and between a loop and the world.

Existing vocabulary does not cover this object. An "agent loop" describes one loop. An "agentic workflow" describes a process with model steps inside a single runtime. An "agent mesh" describes traffic, identity, and routing infrastructure between agents. None names the system of autonomous loops governed by business rules at the seam. Workloop names this, in direct contrast to workflow: a workflow is the acyclic graph owned by a runtime; a workloop is the system of loops that interact under one authority.

A governed agentic workloop is what is often called an "AI-operated company", with a precision that popular usage omits: the operation is agentic; governance is human and deterministic. Loops execute; the authority defines policies, the envelope, and escalation; meta-loops (DEF-14) improve within the envelope. This specification neither describes nor permits an organization in which the model defines its own policy.

2. Conventions and terminology

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY correspond respectively to MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY, per RFC 2119 and RFC 8174, and have normative meaning only when written in uppercase, including plural forms.

Identifiers: DEF-n (definitions), INV-n (invariant), COR-n (corollaries), REQ-n (operational requirements), OPEN-n (open workloop), CONF-n (conformance). Reference clauses by identifier.

"Model" means any component whose output cannot be statically verified, typically a language model, regardless of its temperature or how predictable it may seem.

Sections marked as informative create no obligations.

3. Definitions

DEF-1 · Agentic loop. An autonomous process with its own trigger (event, schedule, or message) and lifecycle, in which a model iteratively decides actions (including tool use and message emission) until a stop condition. It may be durable (with state persisted across failures) or not; durability is not defining.

DEF-2 · Policy authority. The organization, or a unit of it, that creates and operates loops and whose policies and business rules must be enforced. A participant is under the authority when it can be changed, interrupted, and inspected by that authority.

DEF-3 · Channel. An explicit medium through which loops interact: (a) directed message; (b) published and consumed event; (c) mediated shared state: a repository, database, file, or service whose access passes through a mediator that applies a gate. Shared state without a mediator is not a channel (see COR-3).

DEF-4 · Seam. The point at which an interaction crosses the boundary of a loop or workloop (DEF-13): emitting a message or event, writing shared state, or taking an externally effecting action. This is where the gate resides.

DEF-5 · Externally effecting action. Any action whose effect is observable outside the loop: a sent message, written record, publication, transaction, or call to a third-party system.

DEF-6 · Deterministic gate. A computable predicate evaluated at the seam whose result is allow, block, or escalate, and whose value is exclusively a function of deterministic state (schema, allow-lists, effective chain authority, budget, hop count, time window, provenance) and never a model's judgment. Deterministic means: same input, same result; testable; reproducible in an audit.

DEF-7 · Decidable rule at the seam. A business rule whose violation can be detected by a deterministic gate from the message or action and available state: structural, quantitative, authorization, temporal, and provenance rules. A non-decidable rule requires semantic interpretation: appropriateness, truthfulness, tone, or an implicit promise.

DEF-8 · Effective chain authority. The set of permissions resulting from intersecting the authorities of loops along the delegation chain that originated an action. It is never greater than the originator's authority.

DEF-9 · Workloop contract. A specification of a loop's seam, or of a composite workloop at the workloop level (DEF-13): input and output schemas, declared externally effecting actions, authority scope, budgets (cost, hops, rate), and applicable gates.

DEF-10 · Agentic workloop. A system of two or more agentic loops that interact through channels. MAY include non-agentic components (services, APIs, deterministic workflows, mediators), which participate in channels and seams without being loops; the term covers the whole.

DEF-11 · Governed agentic workloop. A system of two or more agentic loops that interact through explicit channels (message, event, or mediated shared state), under a policy authority (the organization that created them), where no inter-loop interaction and no externally effecting action occurs without passing through a deterministic gate that enforces that authority's policies and business rules.

DEF-12 · Open workloop. A workloop whose graph crosses the authority boundary; the operator places gates only on its own arcs and must enforce termination and self-origin marking on every output.

DEF-13 · Composite workloop. A workloop whose participants include other workloops. Each participating workloop exposes a contract (DEF-9) at the workloop level, not only for its loops. Three seams are distinguished: internal (between loops in one workloop), inter-workloop (the boundary of a participating workloop), and external (the authority boundary, section 7). The invariant and corollaries apply at every level. A participating workloop's authority is a subset of the authority of the workloop containing it (COR-1).

DEF-14 · Meta-loop. An agentic loop whose outputs alter other loops (prompts, parameters, models, content, schedules, budget allocation within caps) using data from the workloop itself. It is governed by REQ-6.

Note. "Governed" and "open" describe the scope of authority over the graph. "Conformant" describes satisfaction of this specification (section 8). A governed workloop that violates the invariant is not conformant; it remains governed.

4. Invariant: freedom inside the loop, determinism at the seam

The model is free inside the loop. Nothing crosses the seam without a deterministic gate. In one line: probabilistic autonomy for thinking, deterministic governance for acting.

INV-1 Every interaction between loops MUST occur through an explicit channel (DEF-3).

INV-2 Every interaction between loops and every externally effecting action MUST pass through at least one deterministic gate (DEF-6) at the seam.

INV-3 A gate predicate MUST be exclusively a function of deterministic state and MUST NOT depend on a model's judgment. Model-based verification MAY exist as an additional layer, but it does not count as a gate.

INV-4 A gate MUST NOT be bypassesble, disableable, or rewritable by the loop it governs. The gate resides outside the model's control (hook, mediator, proxy, platform policy), and there MUST NOT be an ungated path to the same seam.

INV-5 The authority MUST classify its business rules as decidable and non-decidable at the seam (DEF-7). Decidable rules MUST be enforced by a gate. Non-decidable rules MUST be converted into structure whenever possible (enumerated actions, typed outputs, templates with validated variables) and, for what remains, be treated as probabilistic (model verification and/or human review), with mandatory human escalation above an impact threshold defined by the authority. Non-decidable rules MUST NOT be declared guaranteed.

INV-6 The deterministic layer alone MUST limit the system's maximum harm (envelope): if the probabilistic layers fail completely, no action outside the envelope is possible.

5. Corollaries

COR-1 · Authority attenuation. The effective authority of an action is the intersection of authorities along the chain (DEF-8). A loop MUST NOT obtain, by delegating to another, permission it does not have. Gates MUST evaluate the effective authority of the chain, not only that of the executing loop. Attenuation also applies to the composition hierarchy (DEF-13): a participating workloop never has greater authority than the workloop containing it. This requires every interaction to carry its origin (COR-2).

COR-2 · Traceability. Every interaction MUST carry an origin identifier (originating loop and authority) and an end-to-end trace identifier, propagated at every hop. Every gate decision MUST be recorded with: timestamp, trace, seam, gate, evaluated input (or its hash), result, and the version of the applied policy. The gate decision log is the system's conformance artifact.

COR-3 · An implicit channel is a defect. Interaction between loops outside a gated channel, through unmediated side effects in files, records, publications, or any shared state without a mediator, is an architectural defect, not an integration. Conformant systems MUST mediate all shared state through a gate or prevent direct access.

6. Operational requirements

REQ-1 · Termination. Every conversation between loops MUST have a hop and/or cost budget, and a cooldown per pair (origin, destination) and subject; gates MUST block or escalate when exceeded. Model loops do not stop on their own.

REQ-2 · Provenance and contamination. Messages between loops MUST separate data from instructions through typed structure. Content originating outside the authority MUST carry a provenance label, and gates MAY restrict downstream actions when such content is present. Gates do not detect injection; they limit what it can reach.

REQ-3 · Idempotency and concurrency. Externally effecting actions MUST be idempotent or protected by an idempotency key. Concurrent access to shared state MUST be serialized (lease or lock) or convergent.

REQ-4 · Published contract. Every loop MUST expose its workloop contract (DEF-9), and the contract MUST be versioned.

REQ-5 · Interruption. The authority MUST be able to interrupt any loop and channel through a means independent of the model, and this capability MUST be testd periodically.

REQ-6 · Meta-loop and self-improvement. Every output from a meta-loop (DEF-14) that alters another loop is an externally effecting action (DEF-5) and MUST pass through a gate. Changes to policies, gates, contracts, or the envelope (INV-6) MUST NOT be executed by a meta-loop; MUST pass through a policy-change seam with human authority, versioning, and a record (COR-2). Self-improvement is allowed within the envelope; the envelope does not modify itself. A meta-loop MUST NOT alter the gates that govern it (INV-4).

7. Open workloop

When the graph crosses the authority boundary:

OPEN-1 The operator MUST apply a deterministic gate to every outbound arc under its control, treating every output as potentially closing a cycle.

OPEN-2 The operator MUST mark the self-origin of every output: out-of-band metadata where the medium preserves it (email or HTTP headers, trace context, trailers), an in-band marker where it does not; and MUST recognize its own marker on input, treating it as a return.

OPEN-3 The operator MUST enforce termination (hop budget, cooldown) and MUST monitor the medium for recurrence (rate, near-duplicates), because markers do not survive third-party semantic transformation.

OPEN-4 The operator MUST NOT assume end-to-end observability or trust third-party gates.

OPEN-5 Every output from a governed workloop outside the authority is an open-workloop seam and MUST comply with OPEN-1 through OPEN-4.

8. Conformance

CONF-L · Conformant loop. A loop is conformant when: it exposes a versioned contract (REQ-4); every output passes through a gate (INV-2, INV-3, INV-4); it propagates origin and trace (COR-2); its externally effecting actions are idempotent (REQ-3); it respects budgets (REQ-1); and it can be interrupted through a means independent of the model (REQ-5).

CONF-S · Conformant system. A governed workloop is conformant when: every seam has a gate, at all three levels (INV-1, INV-2, DEF-13); the rule classification is published and the envelope is defined (INV-5, INV-6); gates evaluate the effective authority of the chain and hierarchy (COR-1); the decision log is complete (COR-2); there is no unmediated shared state (COR-3); every meta-loop complies with REQ-6; and its external seams comply with section 7.

CONF-D · Declaration. "Conformant with Workloop Spec 0.1.0" only MAY be stated when all applicable MUST requirements are satisfied and verifiable by evidence: gate tests and the decision log.

9. What is not a workloop

Informative.

• A single agentic loop, even with hooks. Hooks are intra-loop gates, the direct precedent for this specification, but a loop is not a workloop.
• A workflow with a cycle inside one runtime whose nodes have no trigger or independent lifecycle (a state graph with model nodes, or an orchestrated pipeline). It is an agentic workflow.
• Event-driven integration without a model-decided arc (sagas, ETL, automactions deterministics). It may form a workloop; it is not agentic.
• Third-party loops interacting with yours without you controlling their policy. It is not governed; it is an open workloop (section 7).
• An organization in which the model defines its own policy. It is outside this specification.

10. Canonical example

Informative.

A company operates three loops:

• L1 · Support: receives messages (WhatsApp, DM), qualifies them, and records the lead in the CRM.
• L2 · Offers: reads qualified leads, decides the offer, and sends a proposal that may include a discount.
• L3 · Media: publishes content, responds to comments, and routes interested people to L1.

Channels. CRM as mediated shared state (a mediator applies a gate to every write and read); event bus (lead.qualificado, oferta.enviada, comentario.interessado); direct L1→L2 messages for requests.

Decidable gates. Lead schema; allow-list of opted-in recipients; discount cap by profile; time window; daily message budget; hop budget per conversation; rate per recipient.

Non-decidable rule converted into structure. "Do not promise what you cannot deliver" is not decidable. L2 sends only approved templates with validated variables (value and term within ranges); it does not write free-form text at the seam. What remains semantic goes through probabilistic review and, above the impact threshold, human review.

Chain authority (COR-1). L1 has no discount permission. If L1 asks L2 to "offer 30%", L2's gate evaluates effective authority (origin L1, with no discount permission) and blocks or escalates. L2 grants a discount only when the chain authorizes it.

Traceability (COR-2). A single trace connects the initial DM, the lead in the CRM, and the sent offer; each gate records the decision with the policy version.

Defect (COR-3). If L3 reads the spreadsheet that L1 writes directly, without a mediator, it is an implicit channel. Correction: mediate the spreadsheet or replace it with an event.

Open seam (section 7). A third-party bot comment on L3's post is input from outside the authority; REQ-2 labels the provenance. L3's response is output outside the authority; it complies with OPEN-1 through OPEN-4.

Composition (DEF-13). The three loops form a domain workloop (sales). The company operates others (paid media, content production, data) that compose with this one; the seam between workloops has a gate and a contract at the workloop level, and each one's authority is a subset of the company's authority.

Meta-loop (DEF-14, REQ-6). A data loop reads gate logs and the results of the others and adjusts L1 prompts, active L2 templates, and L3 schedules within the envelope. When it concludes that the discount cap should rise, it does not alter the gate: it issues a proposal to the policy-change seam, which a human approves and versions.

11. Relation to prior work

Informative.

• Code-agent hooks (for example, in Claude Code): deterministic code executed at points in the cycle, capable of blocking an action regardless of what the model decided. This is the intra-loop gate; this specification extends the idea to the seam between loops.
• Policy as code and admission control (OPA, Cedar, Kubernetes admission controllers): a deterministic predicate evaluated outside the governed component. The same separation principle, applied here to business rules.
• Service mesh, agent mesh, and agent gateways: traffic, identity, and routing policy between services and agents. Infrastructure. This specification addresses domain policy at the seam and is complementary.
• Classical multi-agent systems (MAS, FIPA): communication and coordination between agents. This specification assumes an opaque model and focuses on enforcement.
• Loop prevention in distributed systems: RFC 3834 (automatic responses), SMTP hop counting, recursion detection in serverless platforms, and the GitHub Actions rule for events generated by GITHUB_TOKEN. Precedents for the OPEN clauses.
• CaMeL (Debenedetti et al., 2025): capabilities and deterministic policies over data flow against prompt injection. Precedent for REQ-2.
• Confused deputy and capability attenuation (Hardy, 1988; object-capability model). Precedent for COR-1.

12. Name, license, and citation

Name. "Workloop" and "agentic workloop" are terms from the AISAC protocol (Bruno Bracaioli / B2 Tech). Use freely with attribution. The term is not trademarked.

License. This text is licensed under the Creative Commons Attribution 4.0 International license (CC BY 4.0). You may copy, redistribute, adapt, and use it commercially, provided that you credit the author and indicate changes.

How to cite. Bracaioli, B. (2026). Workloop Spec: Agentic Workloop Specification (version 0.1.0). B2 Tech / AISAC protocol. DOI: 10.5281/zenodo.22004648. Canonical URL: https://workloop.b2tech.io. Repository: https://github.com/brunobracaioli/workloop-spec.

13. Versioning this specification

This specification follows Semantic Versioning: MAJOR for incompatible changes to core definitions (DEF-10 through DEF-13) or the invariant; MINOR for new requirements or corollaries and compatible extensions; PATCH for editorial corrections. Drafts use the suffix -rcN. Every change is recorded in CHANGELOG.md.

Appendix A: Conformance checklist