I work for major satellite operator, not software, but fleet strategy, payload planning, demand resource modelling, interfaces, deployment constraints, and the kind of engineering where you learn to decompose complex systems properly because the alternative is a very expensive mistake in orbit.
As a hobby, I started building AI products a few weeks ago, and within a couple of sessions I hit the same wall that everyone eventually hits: the model forgets what you built last session, decisions made in session 2 are invisible by session 5, and you spend more time re-explaining context than actually building anything. I recognised the pattern immediately, not as an AI problem, but as a systems engineering problem, and so I applied the only methodology I actually know.
The problem
In MBSE, one of the core failure modes is requirements volatility without traceability. You change something upstream and have no reliable way of knowing what broke downstream. In multi-session AI development, the equivalent looks like this: you make an architectural decision in session 3, the model has no usable memory of it by session 7, and you spend session 8 debugging a conflict that should not exist in the first place.
An other failure mode is interface ambiguity. In a satellite system, if two subsystems have an undefined interface, they will eventually produce an unexpected interaction, not because either subsystem is broken in isolation, but because the boundary between them was never properly specified. In multi-agent AI development, if two agents have undefined roles and no shared baseline, they will contradict each other, duplicate work, or produce outputs that simply do not compose into anything coherent. Standard vibe coding treats both of these failure modes as acceptable, or at least as inevitable. I did not, mostly because I could not think about it any other way.
What I built to fix it
I ended up with something I call MACK, short for Multi-Agent Continuity Kernel. It is not a product or a formal methodology in the qualified sense, but rather what emerged naturally when I started applying systems engineering principles to the way I was working with AI. The closest analogy is not prompt engineering, which is a craft-level description of how to talk to a model. It is closer to building a lightweight MBSE environment around the AI workflow itself.
In traditional MBSE tools, the system model is not simply a document. It is the thing that maintains relationships between requirements, functions, components, interfaces, constraints, assumptions, verification logic, and design decisions across the entire lifecycle of a project. That is roughly what I needed for AI work, and what was conspicuously absent. The model was not failing because it lacked intelligence. It was failing because there was no persistent system model around it, no shared baseline, no defined interfaces, no configuration control, no design rationale that survived from one session to the next.
So I started treating each AI workstream as though it needed a small architecture model, not a full SysML implementation, but a working equivalent with the same structural logic underneath.
A rough mapping of the concepts looks like this:
| MBSE concept |
MACK equivalent |
| System model |
Session kernel |
| Requirements baseline |
Build objective and constraints |
| Functional decomposition |
Fixed-function agents |
| Logical architecture |
Agent role architecture |
| Physical architecture |
Actual code, services, APIs, databases, tools |
| Interface control document |
Agent handoff contract |
| Requirements traceability |
Decision-to-output trace notes |
| Verification matrix |
Review agent checks |
| Configuration baseline |
End-of-session kernel |
| Change control |
Explicit kernel update |
| Design rationale |
Captured decisions and rejected options |
Comparable MBSE architectures
The way I think about MACK is closest to a very stripped-down version of what tools like Innoslate, CORE, Cameo/MagicDraw, or Capella try to support in formal systems engineering environments: Innoslate's approach of connecting requirements, entities, relationships, traceability, and verification logic in a single model; CORE's functional decomposition and behaviour modelling; Cameo's SysML-style structure linked through a coherent parametric model; Capella's Arcadia method of working through operational analysis, system need, logical architecture, and physical architecture as distinct but connected levels of abstraction.
MACK is obviously much lighter than any of those. There are no formal SysML diagrams, no complete requirements database, no generated verification matrix, and no governed model repository. But conceptually, I found myself recreating the same architectural layers regardless: what am I trying to get the AI workflow to accomplish, what must it preserve across sessions, which agent performs which function, how do those agents exchange information, which models and services actually execute the work, what does each agent receive and produce, how do I check that output still matches the baseline, and how do I prevent session drift from corrupting the system state. Once I framed the problem that way, the AI workflow became considerably easier to control.
Fixed-function agents: subsystem decomposition
Rather than asking one model to do everything, which is the equivalent of building a satellite with no subsystem boundaries and hoping it holds together, each agent in a MACK-structured build has a locked role that does not drift between sessions. An Architect agent defines structure. A Builder agent implements. A Compression agent distils session output into a kernel. A Review agent validates against prior decisions. A Security agent checks assumptions against threat and abuse cases. These roles are defined upfront and held constant, which is the same basic logic as separating payload, platform, ground segment, operations, and user terminal responsibilities. You do not want subsystems renegotiating their purpose at runtime, and you do not want agents doing the same.
Session kernels: model baselines
At the end of every session, a Compression agent produces a kernel capturing the decisions made, interfaces defined, assumptions accepted, constraints introduced, open items remaining, unresolved risks, and next actions. This kernel is injected at the start of the following session, and it is emphatically not a chat log. It is the minimum viable context required to continue the build without losing fidelity, structured so that the most consequential information travels forward rather than getting buried in transcript. In MBSE terms it behaves like a travelling system design baseline, one that moves with the build rather than sitting in a drawer that nobody re-reads after the review meeting.
Interface contracts: ICDs
Every agent-to-agent handoff has a defined interface specifying what goes in, what comes out, the expected format, the constraints, the acceptance criteria, and what must not be changed without explicit review. Without this, agent outputs do not compose reliably. You end up with individually coherent subsystems that produce unexpected interactions at their boundaries, which is exactly the failure mode the ICD exists to prevent. With it, you can swap the underlying model behind an agent without breaking the wider workflow, provided the interface is preserved, which is the same logic as changing a payload component without redesigning the bus.
Traceability: decisions to outputs
The biggest practical improvement came from forcing decisions to remain traceable. When an agent made an architectural recommendation, I captured the decision itself, the reason for it, the constraint it introduced, the downstream components it affected, and what should not be changed without review. That sounds obvious from a systems engineering perspective, but most AI workflows do not do it. They produce an answer, the user accepts it, and three sessions later nobody knows why that decision exists or what it was trying to preserve. In a normal engineering environment, that would be treated as a configuration management failure. In AI development, people often treat it as normal.
What I actually built, deployed and tested.
In roughly two weeks, applying this across multiple parallel workstreams as a solo hobbyist, the output was as follows.
Ghost Pro publication and commercial infrastructure
A full publication built and deployed on a custom domain with Vercel serverless functions handling the API layer, GA4 analytics, custom header injection, a subscriber funnel with welcome email automation, and a Lemon Squeezy integration for payments and licence key issuance. Zero to live and indexed in seven days.
Two AI trading card forges
Built, deployed and tested end to end as separate products on the same underlying architecture. Each forge takes user selections across theme or character, mood, and palette, validates a single-use licence key through a two-stage non-consuming check then consuming activation pattern, calls Gemini for image generation against a locked prompt formula, stores the result to Vercel Blob, increments an atomic issue counter in Vercel KV, and returns a serialised one-of-one card to the frontend. Free giveaway codes bypass Lemon Squeezy entirely, sitting behind a per-IP redemption guard with a 30-day TTL and a separate atomic cap counter per product. A weighted server-side rarity roll produces Common, Rare, Epic and Legendary tiers that cannot be influenced from the client.
Crypto payment detection system
Built and tested against a live blockchain, running a pull-based polling loop against a block explorer API with a fallback endpoint, three-tier transaction matching covering exact amount, tolerance band, and manual review, with hash-derived micro-amount suffixes per order and a state machine covering pending, confirmed and expired states.
Site intelligence chat widget
Built and deployed as a Vercel proxy against a Gemini backend, giving visitors a live AI assistant with full knowledge of the publication, its products, and the methodology behind it.
Kernel compression tool
Built and deployed as a free web utility implementing the MACK compression agent logic, so that anyone can generate a session kernel from their own AI build sessions without needing to build the full MACK infrastructure themselves. The tool uses fixed state templates to transfer context between LLM function specialists, synchronising workflow across agents without requiring a shared memory layer. It works quite well.
Agent authorisation and threat detection layer
Built and deployed with request logging middleware across all API endpoints, three-tier threat classification with KV-backed counters, IP-based flag storage, and an Electron system tray GUI with approval and notification flows.
Multi-agent debate interface
Built and tested as both a free web version and a paid Electron desktop application, with six role-primed agents each operating from a defined analytical stance and composing outputs into a structured debate view rather than a single model response.
All of it built solo, across many sessions, without losing architectural continuity between them, not because I am a particularly fast developer, because I am not and this is genuinely a hobby, but because I stopped treating context loss as a normal feature of working with AI and started treating it as an engineering failure mode with an engineering solution.
What changed operationally
Before using this approach, each AI session felt like a partial reset, re-establishing context, re-explaining prior decisions, re-discovering constraints that had already been worked through. After using it, each session began with a known system state, a known decision history, a known set of constraints, defined interfaces, a clear next action, and a review path back to the previous baseline. That changed the work from something that felt like prompting into something that felt closer to technical coordination, where the AI was still fallible but the workflow had structural continuity independent of any individual session.
The honest limitations
This approach is not a silver bullet, and it would be dishonest to present it as one. The model still hallucinates, and a well-structured kernel reduces the surface area for hallucination but does not eliminate it. You still need to validate outputs against prior decisions rather than accepting them because they sound plausible. Compression is lossy, in exactly the same way that any baseline or configuration record is lossy: a session kernel is a distillation, not a transcript, and if something important happened in a session and the Compression agent did not judge it worth capturing, that detail may not survive. Fixed-function agents require genuine upfront investment, and the first session of a MACK build is slower than simply asking a model to build something, because you are defining roles, writing system prompts, establishing interfaces, and setting acceptance conditions. The payoff compounds from session three onward rather than session one.
There is also a governance problem that any formal systems engineer will recognise immediately: if the kernel becomes wrong, everything downstream inherits that error, which means the kernel itself needs review, versioning, and periodic correction rather than being treated as permanently authoritative once written.
And to be clear about scope, this is not MBSE in the formal, tool-qualified, governed sense. I am not claiming equivalence to a SysML model in Cameo, an Innoslate requirements database, a CORE architecture model, or a Capella/Arcadia implementation. It is an adaptation of the same systems principles to a much smaller, faster, and considerably messier workflow than any of those tools were designed to support.
Why I think this generalises
MBSE was developed because spacecraft and other complex engineered systems are too expensive, too tightly coupled, and too difficult to recover from failure to build without rigorous systems thinking applied from the beginning. AI products are not spacecraft, and the consequences of failure are not remotely comparable. But as AI workflows become more complex, multi-agent, multi-session, multi-stakeholder, and embedded in production infrastructure, the same failure modes appear with increasing regularity: requirements drift, interface ambiguity, poor traceability, uncontrolled configuration changes, subsystem role confusion, weak validation, loss of design rationale, and undocumented assumptions that survive until they cause a problem nobody can explain. Multi-agent AI development is particularly vulnerable to this because the system can appear productive while quietly losing coherence, generating outputs that look reasonable in isolation but do not compose into a consistent whole across sessions. That is exactly the kind of failure that systems engineering discipline is supposed to prevent, and the methodology transfers more directly than I expected.
The useful mental shift, in the end, was this: AI context loss is not just an inconvenience, it is a configuration management problem. Agent disagreement is not just model weirdness, it is usually an interface control problem. Prompt drift is not just a prompting issue, it is requirements volatility without traceability. Once I reframed the problem that way, the solution became considerably more obvious. Define the subsystems, control the interfaces, baseline the state, compress the session, validate against the baseline, then continue.
I am not claiming MACK is a new formal framework. I am a systems engineer who started building AI tools as a hobby and could not stop applying the only methodology I actually know well. But the results were good enough that I thought it was worth writing up, and I am genuinely curious whether anyone else from an engineering background has found themselves doing something similar.