Introducing the state-of-the-art SPEED agentic architecture and speed-core, a fully open-source AI architecture designed to do everything: be fast, be smart, be secure, be reliable, and be easy to use on critical systems. Above all, speed-core was designed with one goal in mind: be reliable enough that you would trust it enough to launch a missile, *without* turning into Terminator-style Skynet.
┌─────────────────────────────┐ fast-path: S → E (skips PLANNING)
│ ▼
┌─────────┐ ┌──────────┐ ┌───────────┐ ┌───────────┐ ┌──────────────┐
│ SENSING │──▶│ PLANNING │──▶│ EXECUTIVE │──▶│ EFFECTING │──▶│ DISTRIBUTING │
│ S │ │ P │ │ E │ │ E │ │ D │
└─────────┘ └──────────┘ └───────────┘ └───────────┘ └──────────────┘
▲ │
└──────────────┘ review loop: E → P (another planning pass)SPEED is both a set of standard permission roles and a template for workflows. SPEED is just an acronym for Sensing, Planner, Executive, Effecting, Distributing. It is the philosophy for how agent workflows are slice into clear roles and permissions to distribute work safely as microsystems. Sensing is essentially “focused only on a narrow input and clarifying it”. Distributing is the opposite, focused only on handling outputs and communicating them. The inner loop, Planning (proposing actions), Executing (choosing/accepting an action), and Effecting (overseeing action) is the decision cycle that makes sure any real actions are done in a useful and safe manner.
Deliberately simple, SPEED is directly inspired by is the military concepts of an AEGIS air defense cruiser’s CIC, an AEW&C control aircraft, and a submarine conn – critical decision making systems which have seen decades of real world use with similar challenges to those we now face with AI.
| Phase | Function | AEGIS analog | Example (spatial domain) |
|---|---|---|---|
| S — SENSING | Observe & Classify | IDS · RSC · EWS | A deterministic process flags an anomalous noise and triggers a sensing agent which performs multimodal processing of the inputs to classify the noise (ie air conditioning fault or person walking and talking) |
| P — PLANNING | Evaluate & Propose | AWC · SUWC · ASWC | A potential fault or intruder has a planning agent pickup to plan a response, perhaps requesting a PTZ camera to pan to that location or to launch a drone to investigate |
| E — EXECUTIVE | Govern & Authorize | TAO | Executive agents authorize (or deny) a camera slew (fewer safeties) or drone launch (more safety rules to check) |
| E — EFFECTING | Supervise & Verify | MSS · GFCS | An agent monitors or controls the drone or camera to confirm it correctly collects the required information (also locked in with any hard-coded rules present) |
| D — DISTRIBUTING | Summarize & Sync | TIC | A reporting agent compiles the results of the effector, potentially passing the data to a human supervisor, a new SPEED cycle, or logging to a database |
speed-core is a library that drafts this concept into a usable “drop in AI harness”. It might disappoint you at first to learn that speed-core is not meant to be a standalone, OpenClaw-type library that you install on your laptop and let run your social media posts for you. Instead, speed-core is written a bit more like FastAPI and Pydantic. That means speed-core is a library that you can easily add into your own existing code (called here the ‘domain library’) to allow you to bring in agentic actions where you need, quickly and in a way you can trust. speed-core doesn’t try to force AI where it doesn’t belong. Instead it lets your pipelines, your services, and your workflows request and define agentic interactions where they need it most, cleanly and elegantly.
First of all, speed-core is designed for safety and human in the loop. It has a three tier model for actions (‘effector’) permissions: auto-approved for lowest risk, agent oversight for most tasks (action plans are reviewed by an agent), and, where the outcome is critical, human approval required. Of course, agent and tool isolation is present as well with a configurable four-tier execution sandbox.
RULES are a standout speed-core safety feature. These are hard-code facts linked to a domain function, such as a boolean ‘if presence sensor in room sensing presence, system cannot be turned off’. These are linked to actions such that they cannot be bypassed by an LLM no matter how much it hallucinates. Rules are easy to add and optional, define only if and where needed. This is a key idea in speed-core, it has rigorous safety when you need it, but that safety never gets in the way as burdensome overhead for users who don’t need it for experimentation.
Ever been frustrated tuning prompts? Annoyed at how small changes can sometimes lead to significantly different results? Well, speed-core was built from Day 1 to support A/B testing, shadow testing, and replay testing on top of a dedicated analytics plane. Uncertain if the fanciest LLM is worth the extra price? Don’t second-guess yourself over whether things improved or not, get solid data to drive your conclusions.
Your imagination is not the limit with speed-core. Here, a dedicated system of Guidance Requests exists for agents to submit tickets when they feel the existing knowledge base is lacking. Know what agents lack so your own efforts are tuned exactly to what is needed most.
Speaking of guidance, guidance is the organizing principles behind prompts and more. speed-core brings order to the chaos of agent knowledge through four core knowledge types: prompts, doctrine, skills, and knowledge. PROMPTS are the first piece of context, only one may ever be included in an LLM call, and a system of priority determines which is used. DOCTRINE is an improved version of agents.md or claude.md, in that it is always loaded if a request matches the tags for that piece of doctrine (a request category, for example). More than one doctrine may be included. SKILLS follow the industry standard for agentic skills, loaded by LLM reasoning on name and description. Finally, KNOWLEDGE is retrievable information retrieved by tool call for context retrieval matching, such as RAG, to provide understanding matching the context. Custom MCP TOOL integrations are, of course, standard.
What makes speed-core guidance so powerful is that you can maintain one prompt or a thousand, and cleanly link each to its necessary use cases and, critically, permissions. The analytics layer is empowering here as well, making it easy to see what prompts are being used and not used and follow challenges like excessive token use or higher latency.
Vibe coding can feel like a superpower. A superpower that almost anyone can access. Yet as impressive as results can be, vibe coding is not without mistakes. speed-core is here to help as well. speed-core is designed to be a reliable heart inside your app, shipping with a clean, user-friendly (and LLM-friendly) API for your UI. Linking actions and rules to your backend is clean and easy with decorators. You vibe code your awesome app on top of speed-core however you like, knowing speed-core provides reliable agent management within.
Ready to go to DEFON 2? speed-core supports coordination modes (named as you please, go to red alert, enable party mode, or enter magical unicorn mode) that can change which prompts and tools are active across the entire system easily.
This is already an impressive set of features, but speed-core does not stop there. speed-core was designed to support advanced cognitive architecture. Requests can generate branching agents to present to an executive agent, which can then choose between options or ask for more.
speed-core is unique in that it is designed for both realtime and batch/session lifecycle modes. What is exciting about that? Agentic requests can easily be tagged as low latency (‘reflexive’) or longer thinking (‘deliberate’) modes to adjust the entire pipeline for speed or deeper thought as the situation demands. Session mode may not sound exciting, but it has a lot of potential for business processes. speed-core can be spun up as part of a serverless process, run, shut down after, in a clean repeating cycle as frequently as needed. speed-core allows you to easily build a tailored agentic orchestrator for your batch pipelines without the mess of trying to manage one hundred domains through a single orchestrator.
Audits will probably not get you excited. Still, auditable behavior is a key feature of speed-core. Decisions can be traced to bundles of details that were used to make those decisions, so reviews can be performed of what happened why. Don’t need that? Don’t worry. Retention can be easily configured, even by action type, so that you store what you need without cluttering your storage drive with years worth of unnecessary data.
LLM calls can get expensive. speed-core knows that. Easily set and view budgets so your project stays on track. Send low latency tasks to fast models, tough decisions to thinking models, and configure fallbacks to cheaper models when budget runs low. Direct workflows to both local and cloud LLMs as desired.
System health status and OpenTelemetry outputs also bring awareness where you need it, to easily keep an eye on the system wherever you are.
Concerned about speed in speed core? speed-core is designed with latency in mind across the entire design. Critically, although written in Python at launch, the kernel is designed to be Rust-ready. Indeed, it should be swappable between Rust and Python kernels for users to choose between fastest and easiest customization.
Try speed-core today. It is the easy and safe choice to make.
</end sales pitch>
I generally trust Agentic LLM AI to work unsupervised on my coding projects. It is easy enough to test the results, and easy enough to revert changes with git. Really the only concern is cost through excessive token usage. But what about using LLMs to control appliances in my house, to turn on the oven or unlock a door? What about neat ideas like being able to have an LLM to task a drone for investigating mechanical or security alerts? There is lots of potential here, but also more risk.
The speed-core library addresses a few major needs I was seeing in orchestration. Firstly, the push towards “agents for everything” has been a bit extreme. Plenty of things should be cheaper and more predictable code, and the domain code should clearly be the base upon which the agentic workflow stands, not some jury-rigged mess of separate systems. Secondly the issues with permissions and sharing of guidances like Skills.md. Skills are a great idea, but their standard of living in a file rather than a database seems a little awkward. Analytics is also forgotten as well, and being able to track model and context quality is really rather critical. Finally of course, the ‘terminator’ risk of rogue agents messing things up has not been well addressed elsewhere.
This design materializes a Capability Gated Architecture which I proposed in my AI blog post, and is designed to keep agents from accidentally or deliberately doing terrible things (see movies: Terminator and War Games, among many others). A sensing agent (most exposed to raw prompt injection) would not by default have direct access to any actions, so it could not, say, run the command that launches photon torpedoes. You could assign an agent access to a low consequence effector (say, turning on a light), and if you did that, the permission linkage would be clear and easy to audit.
You might be wondering how this all started. Or not, in which case, time to switch tabs, because here we go. It all goes back to two things, my enjoyment of a BirdNetPi installation (a bird song classifier) at the family farm, and my annoyance at the coyotes at said farm. Earthy roots for an AI focused product.
The farm is fortunate to be nestled in an area of high biodiversity, and tracking the species present at the feeders and migrating through, has been a lot of fun. But the system did not say where the birds were, nor did it provide the analytics backend I wanted to refine the model and do other sound classification. And I wanted more, because the coyotes, which annoy me greatly, love to howl advertising their location for all to hear. What I really want to do is have a system that can launch a model rocket (whistling type) at their location to drive them off. Maybe not practical, but emotionally satisfying.
Thus, the plan formed for MinimapPR, a sound location based common operating picture (not yet completed, sadly) to track and take action against those coyotes. What I don’t have is the full time staff of something like an Aegis CIC to monitor the picture and diagnose points of confusion, but this is 2026, and I knew that agents could be integrated to improve the system as a command staff.
You can thank a rather buggy memory update to Google’s Gemini for the next phase. As I was refining my agent integration, it decided to answer the question about some of my other projects instead. The answer was wrong, but the possibility was still there. Wouldn’t it be nice to have a domain agnostic agentic system I could integrate safely into all my projects? And thus, after research into some military standards, SPEED was born.
Is this production ready? No, absolutely not! This is too young still. However, I have three integration projects I personally am working on, and hopefully a year from now this will already be a highly tested, polished interface. For now, it should be great for experimentation. Just not for the safety critical systems it was designed to (eventually) manage.
One area that may seem a bit awkward is the guidance registry. It has two sources of truth, the code declared guidances and the API/database controlled guidances. This is a bit inelegant, but the need for both code control and end users configuring guidances via API are clear. One area of future possiblity is using speed-core as a swarm system, with many domains each having their own ledgers, coordinated across the domains. The basis is there, but not yet any true need.
For now, go forth and comment below! I would love to hear whether you think this would be useful, or not, and why!
Colin Catlin, 2026