Operadic Skill Composition

1 Introduction

1.1 Problem

An agent harness is the machinery around a language model: the prompts, the tool surface, the memory, the scheduler. Zhou et al. (27) organise this machinery into four externalization pillars, Memory, Skills, Protocols and Harness. Banu (2) proposes that the pillars already have a formal theory, the ArchAgents Architecture triple $(G, \mathrm{Know}, \Phi)$ of de los Riscos, Corbacho and Arbib (4). In that correspondence the Skills pillar is assigned a categorical role: skills are objects composed via an operad, with three named composition operations, serial, parallel and trace.

The word “operad” carries content. A coloured operad is not a synonym for a graph of tasks. It is a structure with a fixed colour set, operations typed by input and output colours, a substitution operation, a symmetric group action, and three axioms that these must satisfy (9, 5, 26). A runtime called an operad owes an account of its colours, its operations, what substitution means, and whether the axioms hold. Otherwise the claim is a metaphor, and the failure modes of the runtime are exactly the places the metaphor hides.

The correspondence names a coloured operad whose colours are port types and whose operations are skills, with serial, parallel, and trace composition (2). That choice is the hypothesis under test. Because an operad has one output per operation while runtime nodes may have several, a coloured PROP is the necessary comparison structure. Validator and scheduler results apply to both; output representation and interchange do not.

This paper does that work for one system. AgentHero is a production orchestration platform whose unit of work is a validated DAG manifest: a document declaring nodes, edges, roles, tools and policies, executed by a generic executor parameterised over an application supplied handler. The manifest looks operadic. Nodes have declared inputs and outputs. Edges connect nodes. There are combinators named DagLoop, DagMap, DagBranch and DagGate that resemble trace, parallel, conditional and guard. The question is whether the resemblance survives contact with the code.

1.2 Scope

We do not claim that the Skills pillar and a coloured operad are the same thing. The claim is narrower. Under stated assumptions there is a structure-preserving interpretation of the Skills pillar as the operations of a coloured operad whose colours are port types. One production system realises that interpretation on an identifiable fragment, and this paper says where the interpretation fails. The fragment turns out to be small and precisely describable, and the stated assumptions turn out to be load-bearing. The main assumption is that a countable, open, string-keyed set of port names can stand in for a colour alphabet. It is stated as Assumption 3.10, and Section 9 examines what it costs.

1.3 Contributions

The paper defines the skills operad $\mathcal{O}$, a corresponding PROP, and seven source-decidable conditions on a runtime realisation. Applied to AgentHero at commit 1c3ad24, the audit separates properties of dependency order and scheduling from properties the manifest validator does not establish. The complete verdict appears in Table 3.

Two results locate the semantic boundary. Concurrent layers determine a Mazurkiewicz trace class (Proposition 5.8), while a last-write-wins collision prevents execution from factoring through $\mathcal{O}$ (Corollary 5.18). A PROP preserves multi-output invocation identity, but interchange still requires actual output disjointness and strand-local reads (Proposition 7.4). Every implementation claim is tied to a pinned identifier in Appendix A; none reports live execution.

1.4 Series context

This paper is self-contained: every definition it uses is stated here, and every result it proves is proved here. Three companion papers treat the other pillars. Their subject matter overlaps at the boundaries, so we say exactly where, and no object is defined twice under two names.

The port-type alphabet $\mathsf{T}$ is developed in the companion paper on protocols (11). That paper also settles the relation between the wiring operad $\mathcal{W}$ studied there and the skills operad $\mathcal{O}$ studied here. They are distinct operads with different concrete colour sets, related in one direction by a type erasure with no manifest-level section. We use $\mathsf{T}$ only as a generic set of port types and define this paper’s concrete colours below. The Architecture triple $(G, \mathrm{Know}, \Phi)$ and the certificate layer $\mathrm{Know}$ are developed in the companion paper on the harness (12). This paper defines no notion of certificate, and where it observes that a code object is certificate-shaped it says so and stops. The memory carrier of (10) enters here only as one colour that a port may carry, written $\mathsf{Mem}$; the coalgebra itself is neither restated nor used. None of these imports is load-bearing for a proof. The only property of $\mathsf{T}$ used below is that it is a set of colours, and the concrete alphabet analysed here is defined in full in Definition 3.2. No result here mentions a certificate, and $\mathsf{Mem}$ occurs only as a name. A reader without the companion papers loses context and no definition.

Two dependencies run against the presentation order Memory, Skills, Protocols, Harness, and are noted because a reader might otherwise take the order for a dependency order. The port-type alphabet comes from the protocols paper, which is presented after this one. A skill may read and write memory, so the memory carrier can inhabit a colour of $\mathcal{O}$, while nothing in the memory paper depends on anything here. Neither is a circular definition.

1.5 Evidence method

Every claim about code in this paper is a claim about the state of a named file at a named commit, established by reading that file. The pinned commits are AgentHero 1c3ad24011081cd1c15f629ae5fd635237d595b3 (short 1c3ad24) and, as a secondary system, agent-os 61cb3994daf66eae18322bd01853df68d245a681 (short 61cb399). Statements take the form “the implementation at commit 1c3ad24 performs $Y$”. No claim in this paper is a report of a measured run, a benchmark, or observed production behaviour, and none should be read as one. Appendix A lists every code-backed claim with its path, identifier, line range and commit.

Two kinds of statement appear below and they are kept apart. A result labelled Theorem, Lemma, Proposition or Corollary is a mathematical statement about the model of Section 3, proved from the definitions. A result labelled code observation is a statement about the text of a named source file at a named commit; its justification is headed “Source inspection” and consists of exhibiting the relevant lines. A code observation is not a proof about the behaviour of the compiled program: it rests on no formal semantics of Rust, and nothing here is machine checked. Where a mathematical result depends on a code observation, that observation appears as an explicit premise in the statement, so the implication and the empirical premise can be assessed separately. Such a result asserts the implication and nothing more. The claim that its antecedent holds of the source is made only by the code observation itself, at the evidential standard of Appendix A. A reader who rejects the observation rejects the conclusion without any mathematics having failed.

Availability of the evidence. AgentHero is a private production repository, so a reader cannot clone it. Two things are done in compensation, and neither is a substitute for an openly archived artifact. Every claim carries an exact path, identifier and line range at a fixed commit, so it is checkable by anyone with repository access and falsifiable by them. The source that carries the load-bearing claims is quoted in the listings, with any elision stated in the caption. The reasoning from the source text to the claim can therefore be checked from this document alone. Section 9 records the limitation.

Two naming hazards are worth stating at the outset. The identifiers SkillStage, PatternTemplate, WiringDiagram, SkillOrganism, RunContext and BiTemporalMemory belong to Banu’s own reference implementation (2) and do not occur in AgentHero at 1c3ad24. AgentHero independently realises an analogous structure under different names; it does not implement that vocabulary. The secondary repository agent-os contains a paper of its own titled “The AI Operating System, Part II: Tool Interface Layer”. That Part II is not this Part II. Where we cite agent-os we cite it as a prior, same-author case study in a different language and runtime.

2 Background

2.1 The Skills pillar

Zhou et al. (27) describe externalization as the movement of agent capability out of the model’s weights and into inspectable, reusable artifacts. Skills are the pillar that holds procedural capability: a named unit of work with a described interface, invoked by an agent rather than reconstructed by it each time. The industrial form of this idea is a manifest format for a capability, as in the Agent Skills standard (1) and the Model Context Protocol tool surface (19).

One result shapes the pillar in a way this paper can use. Liu (14) gives a typed lambda calculus for agent composition, with mechanised proofs, and reports that a large majority of the compositions found in five deployed frameworks are structurally incomplete with respect to that calculus. That is a statement about the discipline of composition rather than about any one system, and it is the gap a compositional formalism is meant to close. The correspondence this paper tests also appeals to an empirical claim that atomic coding skills compose without negative interference, citing (15). That preprint has since been withdrawn by its authors. No argument here rests on it, and it is cited only to identify what the correspondence appeals to.

Banu (2) closes it by assignment: Skills are “objects composed via operad”, with serial composition $B \circ A$, parallel composition $A \otimes B$, and trace $\mathrm{Tr}(A)$. The assignment is stated at the level of a correspondence table and is not accompanied by a definition of the operad’s colours or a check of the operad axioms in the reference implementation. That is the gap this Part addresses, on a different system.

2.2 Coloured operads

We recall the definition we will use. Nothing here is new. See Leinster (9) for the general theory, Fong and Spivak (5) for an introduction aimed at applied categorists, and Yau (26) for the wiring-diagram case.

Partial composition is the substitution of one skill into one input slot of another. In diagrammatic form, for $g \in \mathcal{O}(\vec{d}; c_i)$ the assignment $f \mapsto f \circ_i g$ is a map of hom-sets, and the two ways of substituting into two distinct slots agree: $$\begin{array}{ccc} \mathcal{O}(c_1,\dots,c_n;c) & \xrightarrow{\scriptstyle -\circ_i g} & \mathcal{O}(\dots,\vec{d},\dots;c) \\[6pt] \big\downarrow{\scriptstyle -\circ_j h} & & {\scriptstyle -\circ_{j'} h}\big\downarrow \\[6pt] \mathcal{O}(\dots,\vec{e},\dots;c) & \xrightarrow[\scriptstyle -\circ_i g]{} & \mathcal{O}(\dots,\vec{d},\dots,\vec{e},\dots;c) \end{array}$$ Here $i < j$, and $j' = j + |\vec{d}| - 1$ is the index of the $j$-th slot after the first substitution has widened the list. Commutativity of this square is the parallel case of associativity: for $i < j$, $g \in \mathcal{O}(\vec{d}; c_i)$ and $h \in \mathcal{O}(\vec{e}; c_j)$, $$\begin{equation} \qquad\text{(1)} (f \circ_i g) \circ_{j + |\vec{d}| - 1} h \;=\; (f \circ_j h) \circ_i g . \end{equation}$$ Informally: plugging two independent skills into two distinct input slots of a third gives the same composite whichever one is plugged in first. Equation (1) is the axiom that a scheduler with an order-sensitive output store can violate, and Code observation 5.16 says exactly when AgentHero violates it.

Free operads matter here because a manifest is a syntactic object. It declares a composite; it does not by itself say what the composite computes. The distinction between the free operad of composites and an algebra over it is where most of the honest content of Section 5 lives.

2.3 Wiring diagrams

Spivak’s operad of wiring diagrams (21), its directed refinement (20) and the algebra of open dynamical systems over it (22) are the standard formalisation of “boxes wired together”. They are the natural home for the Protocols pillar, and Part III (11) develops the wiring operad $\mathcal{W}$ there. This Part uses the operad formalism, not the wiring-diagram operad specifically. As stated in Part III, $\mathcal{W}$ and $\mathcal{O}$ are distinct operads with different concrete colour sets. The only relation between them that is checkable at the pinned commits is a type erasure in one direction. AgentHero’s DagEdge records node identifiers only, so the erasure has no manifest-level section. We cite that statement and do not restate it.

2.4 Audit criteria

An operadic account must specify its colours, operations, substitution, axioms, and algebra. The model below makes each obligation explicit enough to test against the runtime.

3 The formal model

3.1 Ports, colours and interfaces

In the sense of (11), a typed port is a pair $(k, \tau)$ with $k \in \mathsf{Name}$ and $\tau$ drawn from a port-type alphabet $\mathsf{T}$. We now say what alphabet AgentHero supplies.

3.2 Skills as operations

3.3 Operads and multi-output structure

Remark 3.8 shows that $\mathcal{O}$ cannot be the whole story, and it is better to say so now than to arrive at it as a surprise. The runtime’s nodes have several outputs; an operad’s operations have one. Two structures are therefore in play from here on, and the analysis is carried out for both.

The hypothesis under test is stated for an operad, with colours the port types and operations the skills (2), so the operad has to be examined on its own terms. That is the reason not to work only with the PROP. The PROP is nevertheless needed to preserve a multi-output invocation as one syntactic operation. Table 1 records which results belong to which structure. The majority are shared, because they concern the validator and the scheduler rather than the algebra.

3.4 Composites and manifests

Lemma 3.12 is a statement about the presentation data, not about every AgentHero manifest. The runtime does not require a distinguished output or a unique port-level supplier map. Whether execution respects a chosen presentation is separately constrained by Code observation 5.16.

3.5 Effect grading

Operations in a runtime are not pure. AgentHero records this explicitly, so we can model it rather than ignore it.

The relation $\mathbin{\#}$ is a Mazurkiewicz independence relation on node identifiers (17): it is symmetric and irreflexive, and it is the relation under which two operations may be reordered. Definition 3.13 is not an invention. It transcribes DagConcurrencyClass and node_concurrency_compatible, and Section 5 checks the transcription.

An independence relation carries a semantics of its own, and we use it rather than only stating L6 against it. Write $\Sigma_M$ for the set of node identifiers of a manifest $M$, regarded as an alphabet. Let $\mathbb{M}(M)$ be the trace monoid $\Sigma_M^{*} / {\approx}$, where $\approx$ is the congruence generated by $ab \approx ba$ for every pair of nodes whose graded skills are independent (17). An element of $\mathbb{M}(M)$ is an execution order up to the reordering of operations that cannot interfere.

Proposition 5.8 below shows that the trace is determined by $M$ alone even though, by Corollary 5.18, the final store is not. The effect layer quotients correctly where the data layer does not, which is the sharpest positive thing this paper has to say about the runtime’s algebra.

Graded operations are the operations of an operad only if the grading is compatible with substitution, in the sense of a graded or parameterised effect system (8). We do not claim AgentHero realises such a system, and we construct no Kleisli or graded algebra here; Section 9 says what would be needed.

3.6 The laws

Seven conditions separate semantic invariance from manifest-language obligations. L4 asks whether execution factors through the abstract operation. The other conditions concern validation, presentation, scheduling, arity, and effects; their failure does not violate an axiom of the free operad. Each condition is decidable by source inspection for the realisation examined here.

Family A, semantic invariance.

1. Equivariance. If $M$ and $M'$ denote the same operation of $\mathcal{O}$ then $\mathrm{exec}(M) = \mathrm{exec}(M')$. In particular, transposing two siblings in the declaration order of $M$ does not change the result.

Family B, well-posedness of the reading.

1. Input closure. If $\mathrm{val}(M)=\text{ok}$, every declared input slot is either present in $I(M)$ or has a unique compatible supplier among its ancestors.

2. Manifest identity representation. For every colour $c$, the manifest language can express a node that copies a $c$-coloured input to a $c$-coloured output without changing it.

3. Schedule invariance. The execution layering depends only on the dependency relation and declaration order, not on an auxiliary bracketing of a rooted presentation.

4. Arity determinacy. The set of ports a node may read, and their colours, are determined by the node’s signature and not by the composite in which the node occurs.

5. Effect independence. If two nodes are scheduled concurrently by $\mathrm{exec}$ then their graded skills are independent in the sense of Definition 3.13.

6. Well-foundedness. If $\mathrm{val}(M) = \text{ok}$ then its dependency relation is finite and acyclic; in particular no node depends on itself.

L1, L2, and L3 are manifest-language properties, not operad axioms. The free operad already contains identities and satisfies associativity. L1 asks whether validation establishes closure against a declared initial interface, L2 whether the manifest language represents the abstract identity, and L3 whether the scheduler ignores irrelevant presentation brackets. L5 is the condition under which Definition 3.7 assigns a well-defined signature to a node considered on its own. L6 is the condition under which parallel composition is meaningful for effectful operations. L7 is the requirement for a finite execution order. Failures in Family B leave the algebra of the well-coloured fragment untouched; failures in Family A do not.

4 The system

4.1 Runtime

AgentHero’s unit of work is a DAG manifest: a YAML or JSON document parsed into DagManifest, validated by DagManifest::validate, and executed by DagExecutor<H> against an application-supplied handler H implementing NodeHandler. The executor is deliberately domain-agnostic: it moves named JSON values and named artifact references between nodes and never interprets them.

Three crates carry the model. dag-runtime owns the manifest data types and validation. dag-executor owns the operation signature, the store, and the scheduler. plugin-runtime owns externally supplied capabilities and their lifecycle. A fourth, app-sdk, is the read path from an installed application’s directory to an in-memory manifest.

4.2 The mapping

4.3 The operation signature

A skill is a function from an execution context to a result. The context carries the manifest, the node, a reference to the store, an attempt counter, a cancellation token, an optional durability receipt and an immutable execution world.

Listing 1. The operation signature. crates/dag-executor/src/lib.rs, lines 284-292, AgentHero 1c3ad24.

/// App-side node dispatcher.
#[async_trait]
pub trait NodeHandler: Send + Sync {
    /// Execute one manifest node.
    async fn execute_node(
        &self,
        ctx: NodeExecutionContext<'_>,
    ) -> anyhow::Result<NodeExecutionResult>;
}

The store that flows between operations is a pair of key-sorted maps.

Listing 2. The port carrier and its merge, quoted without elision. crates/dag-executor/src/lib.rs, lines 75-90, AgentHero 1c3ad24.

#[derive(Debug, Clone, Default, PartialEq, Serialize, Deserialize)]
pub struct DagIo {
    /// Named JSON values.
    #[serde(default)]
    pub values: BTreeMap<String, serde_json::Value>,
    /// Named artifact references.
    #[serde(default)]
    pub artifacts: BTreeMap<String, ArtifactRef>,
}

impl DagIo {
    fn merge(&mut self, other: DagIo) {
        self.values.extend(other.values);
        self.artifacts.extend(other.artifacts);
    }
}

Listing 2 carries the whole of Remark 3.3 and half of Code observation 5.16. The key type is String, so the port-name set is open. The value type is serde_json::Value, so the carrier imposes no static constraint. And merge is BTreeMap::extend, whose documented behaviour on a duplicate key is to overwrite. The merge is therefore idempotent and associative but not commutative.

4.4 The kind vocabulary

Listing 3. The closed kind vocabulary. crates/dag-runtime/src/lib.rs, lines 107-125, AgentHero 1c3ad24.

pub enum DagNodeKind {
    PrepareInputs, Agent, Synthesizer, Verify, Gate,
    RenderArtifacts, ModerationReady, IngestSource, Tool,
    Artifact, DagCall, Loop, Branch, Map, Approval,
}

The fifteen kinds are a closed set, unlike the port names. Five of them, Gate, Loop, Branch, Map and Approval, are handled by the executor itself rather than dispatched to the handler; the predicate that separates them is is_ordinary_handler_node at dag-executor/src/lib.rs:6340. Those five are the derived operations of Section 6.

4.5 A worked manifest

Listing 4. A complete two-node manifest. agenthero/apps/platform-smoke/dags/tool-policy-smoke.yaml, lines 20-33, AgentHero 1c3ad24.

nodes:
  - id: write_policy_report
    kind: tool
    tool: write_policy_report
    outputs: [result.json]
    required: true
  - id: human_checkpoint
    kind: tool
    tool: human_checkpoint
    inputs: [result.json]
    required: true
edges:
  - from: write_policy_report
    to: human_checkpoint

Listing 4 exposes the gap between a dependency edge and operadic substitution. The first node has output $\texttt{result.json}$ and the second consumes that name, but the second declares no output. It therefore supplies no distinguished generator for the root required by Definition 3.11. The edge imposes execution order; it does not by itself determine a single operation of the one-output operad.

The name result.json occurs in both node declarations, and it matches. Nothing in DagManifest::validate requires that it match. Section 5 establishes this.

4.6 Schema discipline

Two functions in the executor apply a declared schema at dispatch time. The first restricts the store to a node’s declared inputs before checking; the second checks a node’s produced artifacts against its declared outputs.

Listing 5. The early return that makes a node's readable port set depend on its context. crates/dag-executor/src/lib.rs, lines 4367-4372, AgentHero 1c3ad24. The function continues to line 4405, where it filters the store to the allowed names; that part is described in the text and not quoted.

fn contract_input_io(node: &DagNode, inputs: &DagIo) -> DagIo {
    if node.inputs.is_empty() {
        return inputs.clone();
    }

    let mut allowed: BTreeSet<&str> = node.inputs.iter().map(String::as_str).collect();

Listing 6. The artifact output contract. crates/dag-executor/src/lib.rs, lines 4336-4353, AgentHero 1c3ad24.

fn validate_node_artifact_output_contract(node: &DagNode, outputs: &DagIo) -> anyhow::Result<()> {
    let declared: BTreeSet<&str> = node.outputs.iter().map(String::as_str).collect();
    for key in outputs.artifacts.keys() {
        if !is_safe_artifact_key(key) {
            anyhow::bail!("unsafe artifact output key `{key}` returned by node `{}`", node.id);
        }
        if !declared.contains(key.as_str()) {
            anyhow::bail!("undeclared artifact output `{key}` returned by node `{}`", node.id);
        }
    }
    Ok(())
}

Listing 5 is the source of Code observation 5.14: the early return on the empty case means a node that declares no inputs receives the entire accumulated store. Listing 6 is the one genuine colour check on the output side, and it is a containment, not an equality: a node may return fewer artifacts than it declares.

5 Checking the laws

Only L4 depends on whether nodes are read in the operad or the PROP; the remaining conditions concern validation and scheduling.

5.1 Law L7: finite dependency order

5.2 Law L3: schedule invariance

5.3 Law L6: checked independence

5.4 Law L1: input closure

5.5 Law L5: composite-dependent reads

5.6 Law L4: equivariance

5.7 Law L2: manifest identity representation

5.8 Summary

Three of seven hold, one has a sufficient fragment and a counterexample, and three fail. L4 is the semantic invariance condition; the others are manifest-language and scheduler obligations. That is the content of the phrase “skills are operad operations” for this system. One word in Table 3 should not be read charitably. “Conditional” for L4 is not a partial pass. By Corollary 5.18 the executor is not an algebra of $\mathcal{O}$ on all validated manifests. The conditional verdict records a sufficient fragment and a concrete counterexample; it does not assert closure of that fragment under substitution.

Some of these findings needed the formalism and some did not. L1 did not. That AgentHero is dynamically typed and performs no static port check is visible directly from Listing 2; Corollary 5.12 states it precisely but adds little. The other findings are not of that kind. Code observation 5.16 identifies a condition, layer-wise disjointness of sibling output keys, that is checkable in linear time from a manifest and that no reading of the code as “dynamically typed” would suggest looking for. Proposition 7.4 shows the same condition governs the richer structure, so it is not an artifact of the choice of $\mathcal{O}$. Theorem 7.2 separates deterministic correlation from nondeterminism. Proposition 5.8 finds a level at which the runtime is sound, and does so by exhibiting the monoid rather than by asserting soundness. Code observation 6.7 locates the missing check already implemented one layer up in the same repository, which turns a diagnosis into a concrete remedy. The formalism earns its place on those five, not on L1.

6 Derived operations

Banu (2) names three composition operations for the Skills pillar: serial, parallel and trace. AgentHero has five executor-handled combinators. We ask, for each, whether it is a new primitive of the operad or a derived operation, that is, definable from substitution plus data already present.

6.1 Gate and approval as guards

6.2 Branch as an indexed family

6.3 Map as bounded fan-out

6.4 Bounded loops

Listing 7. A loop node with a manifest-fixed bound. agenthero/apps/grokrxiv/dags/review-loop.yaml, lines 158-167 of a node spanning lines 158-175; seven further output keys follow. AgentHero 1c3ad24.

- id: lean_review_fix_code
    kind: loop
    tool: review_fix_code
    loop:
      max_rounds: 3
    inputs:
      - review_loop/proof_obligations.json
      - review_loop/lean_targets.json
    outputs:
      - review_loop/lean/env/env_result.json

6.5 Sub-DAG invocation

DagNodeKind::DagCall is the kind whose name suggests operadic substitution of a whole sub-manifest. At commit 1c3ad24 the executor does not expand it. DagCall appears in dag-executor/src/lib.rs only at line 5439, where it is assigned a derived concurrency class, and at line 6732, where its dag_type is used as a report label. It is an ordinary handler node by is_ordinary_handler_node, so expanding a sub-manifest is the application’s responsibility, not the runtime’s. The nesting that would make substitution literal in the code is therefore delegated, and the executor sees a leaf where the model sees an internal vertex.

6.6 Enforced colour discipline

7 Multi-output nodes

Multi-output nodes require a PROP for a faithful operation signature. That change does not repair the runtime’s order sensitivity.

7.1 Multi-output structure

Passing from $\mathcal{O}$ to the PROP of Definition 3.9 represents a multi-output node as one syntactic operation. A node with output interface $v$ becomes a single operation with output colour list $(v(k_1), \dots, v(k_m))$. A $\mathbf{Set}$-valued algebra remains deterministic, as Theorem 7.2 shows. The change also does not remove the failure recorded in Code observation 5.16, which reappears in a new place.

8 Layer composition

8.1 Layer contribution

The Memory layer supplies state that persists across invocations. The Skills layer adds composability of work: a named unit with a declared interface that can be substituted into another unit’s input slot. It also adds a validation function that accepts or rejects the substitution before anything runs. Table 3 says which parts of that promise the evidence supports: the shape of a composite is checked (L7, L3), its independence structure is checked (L6), and its typing is checked only where a tool declares a schema (L1).

8.2 Lower-layer composition

A skill may read and write memory. In the model this is the statement that the colour $\mathsf{Mem}$ of Part I (10) may occur among the $u(k_i)$ and $v(k)$ of a node signature. Two consequences follow. An operation whose input colour is $\mathsf{Mem}$ is not pure in the sense of Definition 3.13, so L6 constrains where it may be scheduled. derived_concurrency_class assigns ReadOnly to Verify nodes and WorkspaceMutation to RenderArtifacts, ModerationReady, IngestSource and Artifact nodes (dag-executor/src/lib.rs:5427-5436), which is the mechanism by which memory-touching operations are kept out of one another’s way. The composition is also architectural rather than shipped. At commit 1c3ad24 AgentHero has no dependency on ContextFS, so a node that reads Part I’s carrier would do so through a tool, and the model does not depend on any such tool existing.

8.3 Upper-layer composition

A wiring in Part III’s sense (11) can carry a skill at a box. The relation between $\mathcal{O}$ and $\mathcal{W}$ is settled in (11) and not here. They are distinct operads with different concrete colour sets, related by a type erasure whose section is not checkable at these commits, because DagEdge records node identifiers and no port information (dag-runtime/src/lib.rs:636-639). Code observation 5.10(1) is the same fact seen from this side: since validate never reads DagNode::inputs, there is nothing at the manifest level for a port-preserving map to preserve.

At the harness level, (12) takes a manifest as the wiring component $G$ of an Architecture triple. Corollary 5.2 and Proposition 5.4 establish a finite acyclic schedule, but a single operadic operation additionally requires the root and supplier data of Definition 3.11. The import is also not sound for a typed reading of $G$’s ports, by Code observation 5.10, and Part IV’s use should be read with that restriction in place. Two further restrictions are recorded on the Part IV side and are consistent with the evidence here. A manifest edge is a OneOrMany pair on each end (dag-runtime/src/lib.rs:636-646), so a manifest is not a tree wiring in Part III’s sense, and the confinement argument Part III proves by induction over a tree does not transfer to it. The operadic reading also splits each multi-output invocation into coordinate generators, so a harness-level result that depends on invocation identity needs the PROP reading or an explicit coordination constraint.

8.4 The policy envelope

DagToolPolicy (dag-runtime/src/lib.rs:566-579) attaches to each tool a budget in units, an approval flag, and network, filesystem, subprocess and credential policies. What matters here is structural and narrow. The policy is attached per tool, that is per operation, rather than per manifest, and derived_concurrency_class reads one field of it, the filesystem write list, when it assigns an effect grade (dag-executor/src/lib.rs:5406-5425). Part IV reads that per-operation envelope as a stage-indexed fragment of $\mathrm{Know}$, and we adopt that reading by citation, defining no certificate notion of our own. The policy layer is otherwise outside the scope of this paper and is treated in (12).

8.5 Layer dependencies

The dependencies among the four accounts are citations, not definitional entanglements. This paper uses one colour from (10), the port-type alphabet and the $\mathcal{O}$ versus $\mathcal{W}$ question from (11), and the Architecture triple and $\mathrm{Know}$ from (12). In the other direction, (11) cites the colour set of Definition 3.2 in its type-erasure statement, and (12) cites Definition 3.11 when it reads a manifest as harness-level wiring. No definition here is built on a definition there, or the reverse.

9 Limits and counterexamples

9.1 Open colour set

The prospectus for this series records the objection that AgentHero’s DagIo ports are string-keyed with JSON payloads rather than drawn from a small closed colour set. Calling the DAG runtime a coloured operad is therefore an idealisation. Assumption 3.10 states the idealisation, and Definition 3.2 makes it precise: the colour lattice exists, it has a top element, and Code observation 5.10 shows almost every port carries the top. But Example 5.11 shows the real cost is elsewhere. Even granting the idealisation entirely, so that every port has a colour and all colours match, L1 still fails, because the runtime performs no check that an input port has a supplier at all. Openness of the colour set is a modelling inconvenience; absence of a linking check is a structural gap. The two should not be conflated, and Code observation 6.7 shows the repository knows how to close the second.

9.2 Multi-output nodes

An operad represents each output of a multi-output node by a separate generator. A PROP preserves the invocation as one operation, but neither structure makes an external effect deterministic in $\mathbf{Set}$. The obstruction is therefore split: output arity is syntactic, nondeterminism is semantic, and shared-store collisions can still violate interchange (Proposition 7.4).

9.3 Post-validation coordination

This is a genuine break rather than a gap. An operad composite is a finite tree fixed in advance. A coordinator that proposes bounded work after validation is a different kind of object. The bounds are static (max_members at most 64, max_tasks at most 4096, max_depth required to equal 1, all checked at dag-runtime/src/lib.rs:909-969), but the composite is not. The honest statement is that the operad reading applies to static manifests and that manifests declaring coordination fall outside it.

9.4 Effectful operations

Corollary 5.18 already rules out an algebra of $\mathcal{O}$ realising the executor, on order-sensitivity grounds alone. Effects give a second, independent reason. A node of derived class ExternalEffect performs a model call, a process spawn or a network request (dag-executor/src/lib.rs:5406-5444). Two invocations with equal inputs need not return equal results, whereas Definition 2.4 requires each operation to denote a function. So $\mathcal{O}$ as defined here is a syntactic operad and this paper claims no algebra for it.

What is supplied instead is the weaker semantics of Proposition 5.8. The effect word of a run has a well-defined trace, so the runtime does determine an element of a monoid even though it does not determine an element of a store set. A full semantics would need more. The natural target is an algebra valued in the Kleisli category of an effect monad, graded by the classes of Definition 3.13 in the sense of a parameterised effect monad (8). In such an algebra the grading of a composite is computed from the gradings of its parts. The obstruction to constructing it is not the effects but Code observation 5.16: a graded algebra still assigns one value to one operation, so the last-write-wins merge would have to be replaced first. That ordering of the work is the point of this subsection, and it is why the graded algebra is not constructed here.

9.5 Unenforced colour declarations

Example 9.2 is the general lesson of this paper in miniature, on a different system by the same author: writing down a finite colour set does not make it a colour discipline. What makes a colour discipline is a check that runs and can fail. AgentHero has such a check for plugin capabilities (Code observation 6.7) and for artifact outputs (Code observation 5.10(2)), and does not have one for value ports across edges.

9.6 Threats to the reading

All verdicts are relative to one commit; a validation clause added later would change Code observation 5.10 and Code observation 5.16. The laws L1 to L7 are our formulation, chosen for decidability by inspection; a different but equally faithful axiomatisation could redistribute the verdicts. Assumption 3.10 is doing real work: without it there is no colour alphabet and the question does not arise. A reader who rejects Assumption 3.10 should read this paper as establishing that the operad question is not yet well posed for this runtime, which is a weaker but still substantive conclusion.

The most serious threat, for a reader who wants to check the work independently, is that the primary repository is private. Every code observation names a path, an identifier and a line range at a fixed commit. The source that carries the load-bearing code observations is quoted in the listings, with elisions stated in the captions, so the step from quoted source text to claim can be checked from this document. The step from the repository to the quoted text cannot be, by anyone without access. Nothing here is machine checked, and no code observation is a claim about the behaviour of a running system. An openly archived artifact would be strictly better, and its absence is a limitation of the evidence rather than of the model.

10 Related work

Operads and wiring diagrams. Spivak’s operad of wiring diagrams (21) and its temporal, directed refinement (20) give the standard account of boxes and wires as an operad; Vagner, Spivak and Lerman (22) construct the algebra of open dynamical systems over it. Yau (26) treats coloured operads of wiring diagrams systematically. Leinster (9) and Fong and Spivak (5) are the general references we use for Definition 2.1. For many-in, many-out operations, Vallette (23) and Markl (16) are the standard sources on properads and PROPs, and Section 7.1 uses their setting. Hasegawa (6) is the reference for traces obtained as least fixed points in a cpo-enriched setting, which is the structure Remark 6.5 finds missing.

Composition of agent skills. Banu (2) states the correspondence this paper tests and supplies the three-operation vocabulary. That evidence is Banu’s own reference implementation, and the identifiers it names do not occur in the systems studied here. The atomic-skill decomposition that motivates a compositional treatment is due to (15), a preprint withdrawn by its authors after submission; we note it because the correspondence under test relies on it, and we rely on it nowhere. Liu (14) gives a typed lambda calculus for agent composition and reports widespread structural incompleteness in deployed frameworks; Code observation 5.10(1) is an instance of exactly the incompleteness that calculus detects. Wang, Wang and Xu (24) benchmark utility and security of agent skills. That work is cited in (2) under a different author attribution, and we cite the authors listed on the record.

Harness surveys and framing. Meng et al. (18) give an enumerative taxonomy of harness components, against which the categorical account is a contrast rather than a competitor. Pan et al. (25) argue that harnesses are portable objects with algebraic structure; the same work is attributed to a different first author in (2), and we cite the authors listed on the record. Cao (3) supplies the complexity-scaling motivation for externalization that the series’ synthesis takes up. Zhou et al. (27) define the four pillars.

Interfaces and effects. Mazurkiewicz (17) is the source of the independence relation used in Definition 3.13; Katsumata (8) is the reference for graded effects, which is where a semantics for Section 9’s effectful operations would have to live. Joyal, Street and Verity (7) define the trace that Code observation 6.4 shows DagLoop is not.

Prior work by the same author. agent-os (13) contains a tool interface layer paper describing a three-tier registry, capability tokens and sandboxed execution in Elixir and OTP. It is a prior instance of the same design problem in a different runtime, and Example 9.2 draws its colour-discipline example from its source. That document carries its own “Part II” numbering, which is unrelated to this series’ numbering.

Standards. The Agent Skills manifest format (1) and the Model Context Protocol (19) are the industrial expressions of the pillar; both fix a per-skill interface and neither specifies a composition law, which is the gap a formal account is meant to fill.

11 Conclusion

At commit 1c3ad24, AgentHero validates a finite acyclic dependency order and checks interference before concurrent scheduling. It does not establish input closure, represent a generic identity node, or confine returned value keys to declarations. Consequently the executor does not factor through the proposed operad on all validated manifests: distinct declaration orders can produce distinct stores after a key collision.

The operadic reading is defensible only after additional presentation choices and runtime conditions are stated. A rooted output and unique supplier map determine an operation; actual output disjointness gives order-independent merging; and fully concurrent layers determine one Mazurkiewicz trace class. A PROP preserves multi-output invocation identity but does not remove nondeterminism or shared-store collisions.

12 Open problems

1. Declare the initial-store interface and require every node input to occur there or have a unique compatible ancestor supplier. Determine whether existing manifests satisfy that rule.

2. Confine returned value keys to node declarations, then reject layer-wise sibling declaration collisions. Together these checks would make declared disjointness sufficient for L4.

3. Extend Proposition 7.4 from the two-strand case to arbitrary layer widths and to horizontal compositions with shared inputs, which a PROP allows and the two-strand statement does not cover. Determine necessary and sufficient conditions when layers share inputs.

4. Order DagIo by the pointwise extension of the flat order on JSON values and decide whether, for handlers monotone and continuous in that order, a loop node returns the max_rounds-th approximant of a least fixed point. If it does, Code observation 6.4 would become a statement about the absence of a monotonicity requirement on handlers rather than about the loop construct, which would be a more useful diagnosis.

5. Give a semantics for the effectful fragment as a graded algebra over $\mathcal{O}$ using the classes in Definition 3.13, and determine whether derived_concurrency_class is sound for that grading. Soundness here means that a node’s derived class over-approximates the effects its handler can perform.

6. Decide whether the operations proposed at run time by DagCoordination can be brought inside a composite by passing to an operad of bounded-depth trees with a schematic node, or whether Code observation 9.1 is a permanent boundary of the reading.

7. Determine whether the plugin capability lattice of Code observation 6.7 and the port colour lattice of Definition 3.2 can be unified, so that one linking check serves both granularities.

13 Code evidence

Every code-backed claim in the paper has a row. Repository AgentHero is at commit 1c3ad24, agent-os at 61cb399. Line numbers are those of the file at the stated commit. Each entry in the final column is an implementation-level statement established by reading the cited lines. The line ranges let a reader with repository access check each citation against the file. The source carrying the load-bearing claims is also quoted in the listings, with elisions stated in the captions, so the step from source text to claim is checkable without access.

References

[1] Anthropic. Agent Skills: an open standard for agent capabilities. https://agentskills.io. Announced 16 October 2025; opened as a standard 18 December 2025.

[2] B. Banu. Harness engineering as categorical architecture. arXiv:2605.12239, 2026.

[3] Z. Cao. Agentic software: how AI agents are restructuring the software paradigm. arXiv:2606.05608, 2026.

[4] P. de los Riscos, F. J. Corbacho, and M. A. Arbib. Working paper: towards a category-theoretic comparative framework for artificial general intelligence. arXiv:2603.28906, 2026.

[5] B. Fong and D. I. Spivak. Seven sketches in compositionality: an invitation to applied category theory. arXiv:1803.05316, 2018.

[6] M. Hasegawa. Recursion from cyclic sharing: traced monoidal categories and models of cyclic lambda calculi. In Typed Lambda Calculi and Applications (TLCA ’97), Lecture Notes in Computer Science 1210, pages 196–213, Springer, 1997. DOI 10.1007/3-540-62688-3_37.

[7] A. Joyal, R. Street, and D. Verity. Traced monoidal categories. Mathematical Proceedings of the Cambridge Philosophical Society, 119(3):447–468, 1996. DOI 10.1017/S0305004100074338.

[8] S. Katsumata. Parametric effect monads and semantics of effect systems. In Proceedings of the 41st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL ’14), pages 633–646, 2014. DOI 10.1145/2535838.2535846.

[9] T. Leinster. Higher operads, higher categories. London Mathematical Society Lecture Note Series 298, Cambridge University Press, 2004. arXiv:math/0305049.

[10] M. Long. Coalgebraic Memory. Part I of the Agentic Engineering series, The YonedaAI Collaboration, YonedaAI Research Collective, 2026.

[11] M. Long. Typed Protocol Wiring. Part III of the Agentic Engineering series, The YonedaAI Collaboration, YonedaAI Research Collective, 2026.

[12] M. Long. Harness Architecture. Part IV of the Agentic Engineering series, The YonedaAI Collaboration, YonedaAI Research Collective, 2026.

[13] M. Long. The AI operating system, part II: tool interface layer, composition, capabilities, and the Elixir/OTP reference implementation. Manuscript, agent-os repository, papers/latex/tool-interface.tex, commit 61cb399, 2026. The numbering of that document is internal to agent-os and unrelated to the present series.

[14] Q. Liu. $\lambda_A$: a typed lambda calculus for LLM agent composition. arXiv:2604.11767, 2026.

[15] Y. Ma, Y. Liu, X. Yang, et al. Scaling coding agents via atomic skills. arXiv:2604.05013, 2026. Withdrawn by the authors, who report that errors in the data affect the validity of the results. Cited here only to identify a claim made elsewhere; no argument in this paper depends on it.

[16] M. Markl. Operads and PROPs. In Handbook of Algebra, volume 5, Elsevier, 2008. arXiv:math/0601129.

[17] A. Mazurkiewicz. Trace theory. In Petri Nets: Applications and Relationships to Other Models of Concurrency, Lecture Notes in Computer Science 255, pages 279–324, Springer, 1987. DOI 10.1007/3-540-17906-2_30.

[18] Q. Meng, Y. Wang, L. Chen, et al. Agent harness for large language model agents: a survey. Preprints.org 202604.0428.v2, 2026. DOI 10.20944/preprints202604.0428.v2.

[19] Model Context Protocol contributors. Model Context Protocol specification. https://modelcontextprotocol.io/specification/2025-06-18, 2025.

[20] D. Rupel and D. I. Spivak. The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes. arXiv:1307.6894, 2013.

[21] D. I. Spivak. The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits. arXiv:1305.0297, 2013.

[22] D. Vagner, D. I. Spivak, and E. Lerman. Algebras of open dynamical systems on the operad of wiring diagrams. Theory and Applications of Categories, 30:1793–1822, 2015. arXiv:1408.1598.

[23] B. Vallette. A Koszul duality for props. Transactions of the American Mathematical Society, 359:4865–4943, 2007. arXiv:math/0411542.

[24] L. Wang, Z. Wang, and A. Xu. SkillTester: benchmarking utility and security of agent skills. arXiv:2603.28815, 2026.

[25] L. Pan, L. Zou, S. Guo, J. Ni, and H.-T. Zheng. Natural-language agent harnesses. arXiv:2603.25723, 2026.

[26] D. Yau. Operads of wiring diagrams. arXiv:1512.01602, 2015.

[27] C. Zhou, H. Chai, W. Chen, et al. Externalization in LLM agents: a unified review of memory, skills, protocols and harness engineering. arXiv:2604.08224, 2026.