Portable Agent Governance at Solo-Developer Scale: A Four-Domain Case Study

Lionel — Sun, 02 Aug 2026 04:34:51 +0000

Portable Agent Governance at Solo-Developer Scale: A Four-Domain Case Study

Summary

This is about a file-based execution protocol, maintained by hand across four independent, real production projects (a crypto trading system, an e-commerce web app, an AI decision system, and an agent infrastructure layer). The person who built it doesn't write a single line of code. They design the architecture, set the rule hierarchy, and enforce the discipline; an AI writes and technically executes the code. That split isn't presented here as a caveat — it's what the system actually is: not a code project, but a decision-making and oversight protocol. Its quality can be judged independently of whether its designer writes code.

Enterprise AI agent governance (MI9, Microsoft Agent 365, JFrog AI Catalog) offers systems optimized for scale and automation: centralized telemetry, policy-as-code, runtime enforcement. But even their own literature admits two things: (1) coverage varies by framework, and (2) setup and maintenance cost is disproportionate for solo or small-scale use.

The protocol family described here (CORE.md / AGENT.md / SESSION_INDEX.md and their derivatives) runs on a different assumption: not a static template, but a system that revises itself over time. A concrete failure in one project gets written into the file as a dated, justified rule — and that rule gets inherited by a completely different project in a different domain.

1. The limits enterprise governance admits to itself

Enterprise investment in agentic AI governance is growing fast — according to IDC, organizations now allocate an average of 16.7% of total planned AI spending to AI/agent security and governance. But the same sources show implementation lagging far behind intent:

Only 13% believe they have adequate AI governance, despite 76% having a Chief AI Officer.
Among 235 large-enterprise security leaders, 92% lack full visibility into their AI identities; 82% discovered AI agents on their networks they didn't know existed.
More than 40% of agentic AI projects are expected to be cancelled by 2027 due to inadequate controls.

Academic/enterprise runtime governance frameworks like MI9 implicitly admit the same thing. MI9's own paper states: "Coverage depends on the instrumentation capabilities of each framework: callback-enabled frameworks support comprehensive behavioral monitoring, while API-wrapper architectures primarily expose action events." In other words, the design goal is framework-agnostic, but real-world coverage isn't.

Bottom line: enterprise governance is necessary at large scale, but at small-to-mid scale it's both heavy and incomplete.

2. An alternative model: a living protocol under a single decision-maker

Four independent projects share the same three-file skeleton:

CORE.md — fixed principles, mandatory startup sequence, rule-priority hierarchy (Security > Integrity > Quality > Efficiency)
AGENT.md — execution behavior, mandatory decision statements, a self-monitoring/deviation-detection table
SESSION_INDEX.md — cumulative session memory, versioned and compressed over time, with the original archive preserved

This three-file format isn't new by itself — the AGENTS.md pattern is now an industry standard, common across GitHub. What's different is how these files evolve.

Evidence: failure → rule → cross-domain inheritance

In one project (an e-commerce web app), a concrete incident occurred on 2026-07-20: during session-log compression, 7 open issues and 2 decisions were silently dropped. This got written directly into CORE.md:

"v1.2 — Added the '400-line threshold' rule to §7.1 Step 1... Rationale: unjustified loss of items on 2026-07-20 (7 open issues + 2 decisions)"

The same rule shows up in a fourth project's CORE.md — in a completely different domain (an AI decision system / n8n orchestration layer):

"[Previous project]'s 2026-07-20 violation... this project does not inherit that failure."

This is structurally different from "self-correcting memory" examples that stay within a single repo or framework (e.g., GitHub's pro-workflow, or the AGENTS.md "local norms" pattern): the learning here crosses project and domain boundaries.

Pruned to scale

The format isn't a blind template. The same skeleton produces a ~480-line CORE.md in a large, high-risk project (the trading system), but is deliberately trimmed to 97 lines in a smaller-scale project (the AI decision system) — unnecessary weight (an 8-point security self-check, a code-quality scoring system) isn't carried over. This mirrors the "proportional governance" principle argued in enterprise literature by JFrog: "forcing low-risk, productivity-focused agents through compliance checklists designed for high-stakes systems creates operational paralysis." The difference: JFrog sells this as a platform product; here it's applied through human judgment, at zero added infrastructure cost.

3. Structural evidence the system is "alive" — without exposing project specifics

The three-file skeleton above (CORE/AGENT/SESSION_INDEX) is really just the visible spine of a much larger file family. In one project this family grows to more than 20 files (ARCHITECTURE, ROADMAP, ROLLBACK, PHASE_TRACKER, FAILURE_PATTERNS, TEST_MATRIX, CONFIG_SCHEMA, DEPENDENCIES, and multiple versioned SESSION_INDEX sub-files). Without exposing project-specific content, here are four mechanism types that show this family is a living system, not a static template:

Self-inconsistency detection and flagging. The system notices when one of its own files has gone stale, marks it with the session number the drift was caught in, and states which source should be treated as current. A static documentation file doesn't declare its own invalidity.
Dense cross-referencing. Files aren't isolated; each one references others down to the section number, forming a single knowledge graph. This is structurally different from the isolated, single-file AGENTS.md pattern.
Experience-calibrated rules. The failure-pattern log doesn't contain raw, theoretical rules — it contains thresholds and distinctions distilled from real incidents (false alarms, real outages). A distinction like "when is this a real problem vs. noise" can only be written this precisely after accumulated experience.
Organic file splitting. Memory files show a growth pattern that wasn't planned in advance — they split into sub-versions as need arose over time, not according to a predetermined structure.

Together, these four mechanisms show the protocol is something other than a "human writes, AI reads" model: the files shape the AI's output, and the AI's output (failure logs, inconsistency flags) shapes the files back — a reciprocal, cumulative loop. This loop matters especially because the designer can't read and verify the code line by line — so the system's reliability depends heavily on how sound these self-consistency mechanisms are (the cross-referencing in point 2, the self-inconsistency detection in point 1). The code isn't reviewed line-by-line by a human, but there's a multi-layered cross-check at the protocol level.

4. Consistency of the end-to-end agent structure: same protocol, different agent architectures

The CORE/AGENT/SESSION_INDEX family described so far is the shared "skeleton layer" across all four projects. But this skeleton doesn't impose the same kind of agent structure everywhere — each project defines its own agent architecture inside that skeleton, based on its actual risk surface. This matters because it shows where consistency holds, and where it deliberately doesn't.

What stays fixed (the protocol layer): startup sequence, mandatory decision statements, the self-monitoring/deviation table, the rule-priority hierarchy, the versioning logic of session memory — these are structurally identical across all four projects.

What varies by project (the execution/agent layer):

PUSULA has the most explicit multi-agent architecture: Executor and Critic roles are deliberately separated, bound by a rule that they can "never be from the same model family" — meaning the agent that proposes and the agent that reviews are structurally independent. On top of that, there's a separate Policy Engine layer where decisions can only be executed by deterministic code — no AI call is allowed into it. Against prompt injection, it uses a dual-LLM / quarantine pattern: externally sourced text is processed in a context separate from system instructions.
NEXUS is single-agent but relies on a layered validation chain: signal generation, backtesting (CPCV/DSR validation), and a shadow/paper-mode observation layer are separate stages that can't override each other — the "agent" is singular, but the decision process is multi-stage, with each stage able to challenge the one before it.
Bowlera is built around a single customer-facing execution agent; the distinction here isn't in agent count but in rule type — design/brand-integrity rules (motion preferences, calorie information that can never be hidden) dominate over technical/security rules.
Sovereign Engine OS, being an infrastructure layer, organizes its agent architecture more around "authorization routing" — components like githubTokenRouter.ts constrain, at the code level, which operation an agent can perform under which authority.

The real value of seeing this laid out: the protocol layer (how decisions get made, how failures get logged, how work gets handed off) is directly portable across all four projects, while the agent architecture (how many agents, which roles, which separation principles) is redesigned each time based on the project's actual risk surface. What's being carried over isn't a template — it's a decision-making discipline. Agent count and roles are an output of that discipline, not an input to it.

5. The closest examples found on GitHub — and why they're structurally narrower

The closest comparable examples found in a fair search:

Project	What it does	Difference from this system
`rohitg00/pro-workflow`	Self-correcting memory for Claude Code that learns from corrections, compounding over 50+ sessions (`/learn-rule`, `/wrap-up`)	Bounded to a single repo/project; no cross-domain inheritance
Eric Ma's AGENTS.md "self-correction" pattern	When the agent receives a correction, it logs it as a "local norm"	Also single-repo; explicitly scoped as "local," not portable
`charleslwang/MI9-Eval`	Synthetic-scenario runtime governance evaluation	Targets framework-level automation, relying on infrastructure rather than a single developer's discipline

The comparison criterion for any new example added to this table stays the same: does the learning cross a single project/repo/framework boundary into a different problem domain, recorded in a file with a date and a rationale? None of the examples found so far do this.

6. Limits — stated plainly

This is a case study, not a controlled experiment. How many developers have built something comparable hasn't been measured; the claim should stay at "I haven't found a public example," not "this is proven."
Enforcement is behavioral, not technical: there's no physical blocking at the code level, except at critical/high-risk points (e.g., a kill-switch) that are already hard-coded.
The system depends on one person's discipline. If a team grows around it, or a handoff is needed, it will likely need the kind of automated/enforced layer that enterprise models provide.
The technical correctness of the code isn't verified by the designer reading it line by line — verification relies on the AI's own tests, self-audit output, and (at critical points) the observed behavior of running production systems. The protocol is human-designed and human-overseen at the "decision and discipline layer," but AI-dependent at the "line-level code correctness" layer. This is an important distinction for understanding what the system actually is: a decision-making discipline, not a code-review discipline.

Conclusion

Enterprise agentic AI governance still talks about "adaptive governance" as of 2026 mostly as a goal — the industry's own writing frames it as a needed shift from static to dynamic, not as the current state. The system documented here reaches something like that same goal — governance that learns, evolves, and adapts by domain — not through automation but through discipline, across four real projects, running for months. Whether that makes it a "proven rarity" or "an undocumented practice nobody's written up yet" is something the literature will clarify as it grows.

This piece is based on protocol files developed by @Sovereign34 across the NEXUS, Bowlera, PUSULA, and Sovereign Engine OS projects. Repository links for interested readers:

Sovereign Engine OS (UI layer): https://github.com/Sovereign34/sovereign-os-ui
Sovereign Engine OS (core engine): https://github.com/Sovereign34/sovereign-engine
NEXUS (trading system): https://github.com/Sovereign34/NEXSUS
Bowlera (e-commerce web app): https://github.com/Sovereign34/Bowlera_site Note: the CORE.md / AGENT.md / SESSION_INDEX.md protocol files discussed above are kept private. The linked repositories contain the project code those files govern, not the protocol files themselves.

DEV Community: Lionel

Portable Agent Governance at Solo-Developer Scale: A Four-Domain Case Study

Portable Agent Governance at Solo-Developer Scale: A Four-Domain Case Study

Summary

1. The limits enterprise governance admits to itself

2. An alternative model: a living protocol under a single decision-maker

Evidence: failure → rule → cross-domain inheritance

Pruned to scale

3. Structural evidence the system is "alive" — without exposing project specifics

4. Consistency of the end-to-end agent structure: same protocol, different agent architectures

5. The closest examples found on GitHub — and why they're structurally narrower

6. Limits — stated plainly

Conclusion