Skill-Governed Execution Graphs for Multi-Agent Software Engineering: A Monowire by Samiel Study

01Introduction

Agent Skills give AI coding agents reusable procedural knowledge , a written-down way of doing something a specific, well, instead of re-deriving it from scratch every session. That's a real improvement. It leaves one question mostly unanswered: who decides which skills apply to a given piece of work, and when?

In most systems available in 2026, the answer is the execution agent itself, at runtime, on every task. This paper proposes an alternative: that procedural knowledge can be assigned upstream, during the organizational documentation phase of a project, so that by the time a builder agent starts implementing, the relevant skills are already attached to the work rather than something it has to discover. We call the resulting structure a Skill-Governed Execution Graph (SGEG).

The idea emerged while designing Monowire, a Samiel product and multi-agent software engineering system in which AI departments , Product, Systems, Backend, UX, Infrastructure , reason about different aspects of a project and produce organizational documentation. Monowire is the environment this idea was noticed in, not the contribution itself. The methodology is intended to stand on its own, independent of any particular implementation.

This is a working hypothesis, not a validated result. Section 12 states plainly what appears to already exist in the literature, and it turns out to be a lot.

02Problem Definition

Most AI coding workflows reduce to: a task arrives, an agent receives it, the agent decides what context and knowledge are relevant, and the agent executes. Agent Skills improve the "what knowledge" part by giving the agent a library of written procedures to draw from. But the agent still has to decide, on every task: what skills do I need, what documentation should I read, what procedures apply, what should I do next. That's a real reasoning burden, and it's re-paid on every single run.

The alternative structure this paper investigates is:

Human Intent → Organizational Reasoning → Department Documentation → Skill Assignment → Execution Graph → Builder Agent → Skill Enforcement → Implementation

The change is where the "which skills apply here" decision gets made. Instead of the execution agent discovering it at runtime, the organization's own planning and documentation process determines it upstream, before implementation begins.

03Background

Three lines of prior work sit behind this proposal. Multi-agent software engineering systems such as MetaGPT and ChatDev assign roles to agents and require structured intermediate artifacts , documents, not just code , before implementation proceeds, an idea extended by frameworks like BMAD-METHOD, which shards planning documents into execution-ready story files. Agent Skills, as formalized by Anthropic's open Agent Skills format, package reusable procedural knowledge into loadable, filesystem-native units. And a fast-moving 2026 sub-literature on skill compilation and execution graphs , discussed in full in Section 4 , has independently begun turning prose skills into structured, typed, or graph-based representations to make agent behavior more reliable and auditable.

This paper sits at the intersection of the first and third. The second , Agent Skills themselves , is the substrate both draw on.

04Existing Approaches

A direct search of the 2026 literature turns up substantially more relevant prior art than the original framing of this idea anticipated. The table below lays out the closest work found.

Multi-agent software engineering with structured documents

MetaGPT assigns software-engineering roles to distinct agents and encodes Standardized Operating Procedures into their prompts, producing structured intermediate artifacts , a PRD, design docs, interface specs , before code generation. ChatDev takes a similar premise through a "chat chain." OrgAgent goes further toward this paper's concern directly: it organizes a multi-agent system into vertical layers modeled on a company (CEO/CTO/COO at the top), where the top layer's output determines the "execution configuration for the downstream process." That is close in spirit to organizational planning governing what happens downstream , the missing piece, from this proposal's angle, is that OrgAgent's downstream configuration is a task routing decision, not a graph of skill-bearing documentation nodes.

Mandatory runtime skill invocation

Superpowers, an open agentic-skills framework for coding agents, enforces a "skill-first" rule: if there is even a small chance a skill applies, the agent must invoke it before acting, including before asking clarifying questions. This is real, working skill enforcement, in production use across several coding-agent platforms. It is not upstream assignment, however , the agent still performs the "does this skill apply" check itself, on every task, at runtime. It solves the "agents skip skills" problem without touching the "who decides which skills are relevant" problem this paper is about.

Skill compilation and execution graphs

This is the closest prior art, and it needs to be named specifically. AIP (Agent Instruction Protocol, Blumenfeld & Webber, June 2026) models a skill as a directed execution graph , discrete steps as nodes, typed input/output edges, a schema-validated YAML specification , with a compiler meta-skill that translates existing prose skills into this form. Compiling to AIP raised task pass rate from 53% to 67% in the reported evaluation. SIGIL, built around a typed intermediate representation called AG-IR, compiles a single prose skill into an executable harness that separates model-owned cognition from code-owned mechanism; compiled harnesses performed 86% of mandated steps versus 56% for prose, invariant across model generations. Related systems , SkVM (a skill virtual machine), SkillCompiler, and SkillSmith , pursue overlapping goals: compiling skills into typed, more reliably executable forms, sometimes across heterogeneous model backends.

Every one of these systems operates on a single skill: it takes one prose procedure and turns it into a more structured, enforceable representation of that procedure's own internal steps. None of them, as far as this review found, graphs the relationship between a project's organizational documentation and which skills that documentation implies , the graph in AIP is internal to one skill; the graph this paper proposes spans many skills across a project's departments.

Governance and runtime enforcement, more broadly

A separate line of work supervises agent behavior at runtime without changing the underlying representation: AgentSpec provides a domain-specific language of symbolic rules checked against each run; GuardAgent and ShieldAgent evaluate or block actions at the tool boundary. A 2026 formal-methods paper, "Specifying AI-SDLC Processes," proposes a protocol language for human-agent responsibility boundaries across the software development lifecycle, explicitly critiquing systems like MetaGPT for encoding process only in agent prompts, where it can drift. That critique applies to this proposal too, and is addressed directly in Limitations.

05Skill-Governed Execution Graphs

A Skill-Governed Execution Graph is a structure in which project documentation nodes , not individual skill files , carry references to the skills relevant to the work they describe, and are connected to each other in the order implementation is expected to proceed. The graph is a property of the project's knowledge base, assembled as documentation is written, not a property of any single skill.

This is the central distinction from AIP and SIGIL: those systems graph inside a skill. This proposal graphs across skills, at the level of a project's own documentation, before any individual skill is invoked.

06Architecture

The conceptual architecture below shows how a founder's conversation flows through organizational reasoning into a graph that governs execution. Presented as a motivating implementation, not the contribution itself , Monowire is one environment this can be explored in, not a claim about a new AI architecture.

07Skill Assignment

During documentation, each department reasons about the work it's describing and identifies which existing skills that work requires , not by inventing new skills, but by selecting from an approved registry (Section 10). A backend department documenting an authentication system, for instance, wouldn't just write "authentication uses PostgreSQL" it would identify that the work requires several existing skills together: backend architecture, security, database design, API design, testing.

A metadata representation could look like this , illustrative only, not a claimed final format:

type: execution_spec
department: backend

skills:
  - backend-architecture
  - security
  - database-design
  - api-design
  - testing

next:
  - authorization

Whether YAML frontmatter, a graph-native format closer to AIP's schema, or something else entirely is the better representation is an open question this paper doesn't resolve , see Section 16.

08Skill-Carrying Documentation

Because each documentation node references its required skills and its next node, the documentation as a whole forms a graph rather than a flat library:

Whether this specific concept documentation-as-execution-map, distinct from documentation-as-knowledge-repository already exists under different terminology elsewhere is worth flagging honestly: the closest framing found is "executable documentation" and documentation-driven development discussions in the spec-driven-development ecosystem, which treat a specification as the thing implementation is generated from and validated against, rather than a description written after the fact. That's a related but not identical claim , specs there are typically per-feature, not a persistent, department-spanning graph.

09Execution Guards

Every execution document can carry a small guard, conceptually:

• Load all skills referenced by this document.
• Verify required dependencies.
• Follow the referenced skill instructions.
• Check the next execution document.
• Do not bypass documented constraints.
• If a required skill is unavailable, stop and report the dependency.

This is directly inspired by the mandatory-invocation behavioral philosophy in systems like Superpowers, and it should be credited as such. Superpowers did not originate with this proposal, and neither did skill enforcement generally Superpowers already enforces skill invocation in production, and SIGIL already compiles enforcement into a harness with a measured compliance rate. What this section investigates is narrower: whether enforcement that reads its instructions from an upstream-assigned execution graph, rather than deciding on its own what applies, behaves differently a question Section 14 proposes testing rather than answering.

10Agent-Agnostic Execution

The skill system is not meant to belong to a particular model vendor. A skill is a portable procedural artifact; the execution graph determines which skills are relevant; the agent Claude, GPT, Gemini, an open-source or local model carries out the work within those constraints. This creates a three-way separation:

This three-way split isn't new either. It echoes, in different language, the Mission Kernel principle from Monowire's own earlier design work deterministic structure owns organizational state, AI reasons within it and the broader multi-agent-orchestration convention of separating a coordinating layer from execution layers (seen in OrgAgent's hierarchy and in general orchestrator-driven multi-agent SWE patterns). The specific vocabulary of "strategic / procedural / tactical" doesn't appear to map exactly onto any one source found in this review, but the underlying separation-of-concerns idea clearly isn't original to this paper.

11Relationship to Existing Skill and Harness Systems

To state it plainly: the mechanisms this paper proposes execution graphs for skills, compiling procedural knowledge into a more structured and enforceable form, mandatory skill invocation are each already demonstrated, working, and in some cases benchmarked, in systems published earlier in 2026. AIP uses the literal term "execution graph." SIGIL and AG-IR already separate model-owned reasoning from code-owned mechanism. Superpowers already enforces invocation in production coding agents. None of this originated here, and none of it should be attributed to Monowire.

12Is This Actually Novel?

13Hypotheses

Two hypotheses follow from the proposal, stated so they can be tested and potentially falsified:

• H1. Upstream skill assignment reduces the amount of procedural reasoning an execution agent must rediscover at runtime, relative to an agent that selects its own skills from a registry on every task.
• H2. The same execution graph produces more consistent behavior across different underlying agent models than either no skill structure or runtime-only skill selection does.

Both are stated as hypotheses because they are currently untested. Section 12's finding that the underlying mechanisms are largely established elsewhere does not resolve either hypothesis; it just means the mechanisms needed to test them mostly already exist and don't need to be built from nothing.

14Proposed Evaluation

Proposed evaluation no results yet. The following is an experimental design, not a completed study. No numbers below are real; none should be read as results.

Proposed metrics, none yet measured:

• Procedural compliance required steps actually followed, per SIGIL's methodology of comparing agent behavior against a skill's own mandated steps
• Architectural consistency across repeated runs of the same task
• Constraint violations and rework required after initial implementation
• Task completion rate
• Context consumption (tokens) per completed task
• Number of required procedures skipped
• Execution variance between different underlying agent models on the same graph

The two questions this design is meant to answer directly: does upstream skill assignment reduce the amount of procedural reasoning the execution agent has to rediscover, and does the same execution graph produce more consistent behavior across different agent models than runtime selection does. Both are testable with the conditions above; neither has been tested yet.

15Limitations

• Incorrect or stale skill assignment. If a department assigns the wrong skills, or documentation drifts out of sync with what a skill actually requires, the execution agent inherits that error with less opportunity to notice and correct it than a runtime-selecting agent would have.
• Conflicting skills. Two departments referencing skills with contradictory guidance for overlapping work is a real failure mode this proposal doesn't yet resolve.
• Over-constraining agents. Upstream assignment can remove flexibility a capable agent would have used well, especially on work that doesn't fit the anticipated shape.
• Graph complexity and documentation maintenance. A graph is another artifact that has to be kept current; unmaintained, it becomes actively misleading rather than neutral.
• Skill-selection errors happen upstream now, not at the point of execution which may make them harder to catch, since the person or agent doing the assigning is further from the actual implementation detail than the executor would be.
• Context overhead. Carrying graph metadata and multiple assigned skills into every execution step has a real token cost that has to be weighed against any reliability gain.
• Agents can still ignore instructions. As the AI-SDLC protocol-language critique of MetaGPT-style systems points out, process encoded only as instructions, even upstream-assigned ones, is subject to drift unless paired with a genuinely separate enforcement mechanism, not just another layer of prose.
• False confidence created by documentation. A well-organized execution graph can look authoritative without actually being correct, which may make errors harder to question than an agent visibly improvising would be.
• Procedural compliance is hard to evaluate in the first place, independent of this proposal, SIGIL's own reported baseline compliance rate (56% of mandated steps followed from prose) suggests the underlying measurement problem is real and unresolved industry-wide, not specific to this design.
• The central open question: does adding this structure actually improve outcomes, or does it simply relocate complexity from runtime reasoning to upstream documentation maintenance, without a net reduction? This paper does not know the answer. That is precisely what Section 14 is designed to find out.

16Open Questions

• Is YAML frontmatter the right representation for skill-carrying documentation, or does a graph-native format closer to AIP's schema serve better once a project has enough nodes to matter?
• What's the right unit of graph node a single document, a department's whole knowledge base, something in between?
• Should skill assignment be revisited automatically as documentation changes, and if so, by what mechanism, without re-litigating Monowire's own Mission Kernel concerns about letting AI silently rewrite organizational state?
• A controlled skill registry (skill candidate → human or governance review → approved skill → registry) is proposed as a way to let the system learn recurring patterns over time without permitting uncontrolled self-modification. This extension is intentionally undeveloped here and left for future work rather than designed in depth.
• How does this proposal's execution-graph scope interact with AIP if both were used together a project-level graph of documentation, each node itself pointing at an AIP-compiled skill? That composition is untested and might be where the more interesting engineering actually is.

17Conclusion

The honest version of this paper's contribution is smaller than its starting hypothesis. Execution graphs for skills, typed skill compilation, and mandatory enforcement are not new in mid-2026 they're an active, competitive research area with working systems and reported benchmarks. What this paper investigates is narrower: whether graphing skill assignment across a project's organizational documentation, upstream of any individual skill being compiled or invoked, behaves differently from either no structure or runtime-only selection. That is a hypothesis with a proposed test attached to it, not a demonstrated result, and Section 15 lists real reasons it might not pan out.

The strongest version of this work is one that survives an honest attempt to disprove it. This paper is the hypothesis and the test design, not the proof.

—References

1. Hong, S. et al. "MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework." arXiv:2308.00352, 2023.Role-based SOPs and structured planning artifacts required before code generation.
2. BMAD-METHOD: Breakthrough Method for Agile AI-Driven Development. GitHub, bmad-code-org.Planning documents sharded into execution-ready story files for implementation agents.
3. "OrgAgent: Organize Your Multi-Agent System like a Company." arXiv:2604.01020, 2026.Hierarchical, company-modeled agent system where a coordinating layer sets execution configuration for downstream layers.
4. obra. "Superpowers: An Agentic Skills Framework & Software Development Methodology." GitHub, 2026.Mandatory skill-first invocation protocol for coding agents, in production use.
5. Blumenfeld, Z. and Webber, J. "AIP: A Graph Representation for Learning and Governing Agent Skills." arXiv:2606.04781, 2026.The closest prior art models a single skill as a directed execution graph with typed I/O edges and a schema-validated specification.
6. Dantanarayana, J. L. et al. "SIGIL: Compiling Agent Skills into Typed Harnesses." arXiv:2607.27309, 2026.AG-IR, a typed intermediate representation compiling one prose skill into an executable, model-independent harness.
7. "SkillSmith: Compiling Agent Skills into Boundary-Guided Runtime Interfaces." arXiv:2605.15215, 2026.Skill compilation into typed runtime interfaces, benchmarked against a separate skill virtual machine (SkVM).
8. "Agent Skills in LLM Systems." Emergent Mind, 2026.Survey covering skill representation, acquisition, and the execution-graph framing of AIP specifically.
9. Prifti, Y. "Specifying AI-SDLC Processes: A Protocol Language for Human-Agent Boundaries." arXiv:2606.20615, 2026.Formal critique of prompt-encoded process (including MetaGPT-style SOPs) as subject to drift without separate enforcement.
10. Anthropic. "Agent Skills" Claude Platform Docs.The open, filesystem-native prose skill format that this line of work compiles from.