speed-core 0.1.0

Agentic governance and workflow infrastructure for domain systems

SPEED-CORE

pip install speed-core
# With LLM provider support:
pip install "speed-core[litellm]"
# With SQLite/PostgreSQL durable backends:
pip install "speed-core[postgres]"

Sensing, Planning, Executive, Effecting, Distributing (SPEED) defines agentic decision roles, which is a type of CGA (Capability Gated Architecture). SPEED is an architecture for stateless decision workers performing continuous refinement of a a domain model and implementation of actions (effectors) based upon the domain model.

Inspired by military C2 systems (AEGIS CIC, AWACS, Submarine Conn) whose rules of engagement and structured procedures form a strong basis for agentic LLM governance, enabling an Information Center without full personnel deployment.

General Goals: Coherence, Timeliness, Truthfulness, Actionability, Governance. SPEED agents coordinate, interpret, and govern — they don't block the critical path.

While Timelineness is an important goal, and the acroynm is SPEED, note that this will likely not be the fastest agentic pattern due to the formal patterns it follows.

SPEED for the MinimapPR Common Operating Picture

The technical core is sound localization. Combined with ifcplot (detailed 3D structure database) and Home Assistant (consumer device integration), this becomes a Common Operating Picture with CIC-style agentic LLM coordination above deterministic localization, tracking, and rules enforcement. The system models real-time and long-term environment, tracking and coordinating spatial automations (including future drones and autonomous equipment). Military patterns are followed because they are among the most tested examples for these tasks, and some use cases may see integration by trained NATO personnel.

The goal of this TODO.md is to cover an expansive vision of a product which may take many years to build, in order that all design elements are built with future needs in mind.

Of the main tasks here, one is bringing Agentic (LLM) C2 deeper. The design assumes high-quality LLMs (2026 state of the art) can fill staff-style decision and coordination roles analogous to an AEGIS CIC, while the underlying execution plane remains deterministic and stateful.

For an initial design, the following agents are proposed, which map to SPEED roles: Tactical Action Officer: ultimate decision maker agent that coordinates the intent of the system commander (here the human controller is the commanding officer). Sensor Supervisor: responsible for clarifying data about sensors (for example, helping classify a track, dynamically adding extra noise cancellation preprocessing if facing interference, etc). Operations Coordinator: responsible for multimodal fusion and reacting to events like a loss of track or loss of sensor. Can combine camera feeds and sound classifications along with information lookups to confirm classification, IFF, etc. Engagement Control Coordinator: responsible for overseeing individual effector engagements. Tactical Information Coordinator: interacts with external agents to provide information import and export

Unlike humans, agents are stateless — many copies can be spun up as needed, but they need a real-time log of past actions. An agent ledger database is necessary (implemented via the EventLog Blackboard Pattern + Distributed Locks and Leases). Agents operate at a higher cognitive tier, but are strictly governed by the rules/policy engine. They sit above real-time systems like TDOA localization. The deterministic execution plane continues regardless of whether any agent is active. Hard-coded rules still prevent unsafe actions (e.g., activating sprinklers if high-confidence human tracks are present).

One potential side use: an agentic workflow for classifying unknown signals using LLM models and query tools, pulling examples from online until a high-confidence match is found, gradually building a training dataset.

The MinimapPR agent layer acts as the Operators and staff (interpret, recommend, coordinate, report), with humans as Commanders. It does not replace the deterministic execution plane. This requires proper integration of LLM rules into the full ROE and protocols. Authority must be strictly defined (e.g., lights are safe to authorize autonomously, but door locks always require human authorization). Structured messages are already part of a military-grade COP and useful for LLMs. A separate narrative schema may be defined for human readability. Some alerts fire directly from deterministic logic (e.g., high-confidence fire alarm). Others go through an LLM C2 pathway. Agentic workflows may also build protocols for frequent procedures, gradually removing LLM overhead.

COP (Common Operating Picture) and SPEED for Time Series

Unlike MinimapPR where tracks represent concrete objects, time series tracks represent derived "composite trends" — long-term (consumer demand), short-term (discrete anomaly events), or predictable (holidays). Goals: build composite tracks with high accuracy, explain individual sensor data fully through composites, and minimize the number of composites needed (e.g., one composite anomaly for a winter storm affecting multiple series). Open questions: how composites compose into each other (a winter storm impacts overall demand but isn't part of its long-term trajectory), and how related trends reference each other across geographies. Uniquely here, forecast tracks of individual series are desired. These should be built from or conform to their related composite tracks. An important downstream question is staffing (warehouse or data center capacity). Products undergo frequent packaging/platform changes with varying impact on demand and operations. Goals: annotate changes on historical data, assess impact, and estimate future planned event impact from historical patterns.

Agentic LLM workflows are seen as critical for making this system feasible and increase its sophistication over time. They need to interact cleanly with deterministic processes (which handle most needs, and trigger agents where needed), rigidly defined rules and processes, and human oversight and input.

Three track types: sensor (raw time series), digital twins (reconstructed from derived), and derived tracks (underlying factors like consumer demand, category demand, holidays). Derived tracks and digital twins have forecast values; sensor forecasts are the digital twin forecast.

• Identification: anomaly/not-anomaly, trending, fading, etc.
• Effectors: internal management (new derived tracks), direct actions (marketing spend), tickets for human review
• Rules scope: product categories or service lines rather than geographic zones
• Policy/ROE Engine: manage components (holiday tracks stay holidays, not anomalies) and constrain effectors (budget limits)
• Versioning: important, with functionality to backtest policy changes

Limitation: can adjust marketing allocation but won't create new materials. Focuses on operational questions ("how many staff tomorrow") not strategic ones ("should we build a new warehouse"), though agents may raise tickets for such analysis.

SPEED roles mapped:

• Sensing: deterministic anomaly detection; agentic review for gray-area data
• Planning: graph auditor suggests constraints; event linkage agent proposes linked events
• Executive: reviews plans against policies, approves effectors
• Effecting: supervised execution loop that reruns graph with new params to assess accuracy
• Distributing: explainable forecast outputs with anomaly/changepoint annotations

Details on the time series COP - Time Variant Architecture COP

Decomposition model: All time series decompose into trend, seasonality, level shifts (sudden jumps, usually from metric redefinitions), holidays, and anomalies. New series start with univariate breakdown; only holidays (geo-shared) form initial cross-series connections.

Graph construction from shared stories: Anomalies and changepoints are linked to labeled stories, forming cross-series connections. These shared stories provide constraints for building the trend graph. Series with shared changepoints should derive them from a common derived track. Impacts may differ in direction/magnitude (winter storm increases shovels, decreases other products). Key techniques: Bayesian edge priors, lag-tolerant linkages, regularization. Graph built in numpy/scipy (connections mask), forecasts via PyTorch/Jax. Linkages represented by masked sparse attention (time-varying).

Component scope: Trend graph is the primary structure. Holidays and anomalies have their own subgraphs. Seasonality is fully local.

What-If backprop: Users input adjustments to forecasts, backpropagated as constraints with attention frozen. Bayesian updating shifts high-variance components first, preserving deterministic holidays and high-confidence national trends.

Hard constraints:

• Level shifts strictly quarantined as local intercept adjustments (β_local); never propagate through edges
• Trends must be modeled from derived components (strong penalty on independent trend usage)
• Penalize correlation between derived tracks and known deterministic components (holidays, day-of-week)
• Encourage derived track smoothness Graph updates: Incremental (pull old weights, learn for new/removed series). Learning starts with 1-step-ahead, extends to longer windows. Long horizons focus on trend, seasonality, holidays — no far-ahead anomaly prediction.

Digital twin composition: Trend + seasonality + holiday + level shift + anomaly, combined via attention (not purely additive/multiplicative).

Hierarchical reconciliation: Orthogonal cascading with differentiable reconciliation. Network outputs distribution parameters (μ, σ²) optimized via NLL. Reconciliation updates covariance matrices across geographic nodes.

Agent roles: Build events databases from company/news stories (external pipeline), link anomalies/changepoints to stories, audit graph and propose constraints where connections contradict known business procedures.

COP and SPEED for Personal Digital Assistant

Potential third use case (not built out): real-time data from fitness wearables and calendars, with tracks for health states and time allocation. Effectors like bedtime notifications. Could integrate with a household MinimapPR instance (admin/viewer access levels).

SPEED for Conversational Agents

SPEED may also frame conversational agents: SENSING reviews inputs (spelling, adversarial detection), PLANNING processes content and pulls context and recommends effector, EXECUTIVE reviews against rules and triggers an effector to respond, EFFECTING is the actual response generation (a dedicated code creator, or code reviewer is called). DISTRIBUTING applies formatting and reviews if additional actions are needed before returning output to user. In this case, the COP is the collection of memories and skills attributed to the User (not even needing a full separate domain model, but simply rules and policies to guide how these memories are created, organized, and used). The higher overhead of this pattern make this more suited for conversational platforms requiring higher response quality (for example, a banking agent).

Time Series COP Flow Chart

graph TB
    classDef input fill:#eceff1,stroke:#607d8b,stroke-width:2px;
    classDef processing fill:#fff3e0,stroke:#ff9800,stroke-width:2px;
    classDef agent fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px;
    classDef core fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px;
    classDef output fill:#e8f5e9,stroke:#4caf50,stroke-width:2px;
    classDef user fill:#ffebee,stroke:#f44336,stroke-width:2px;
    classDef strict fill:#ffebee,stroke:#b71c1c,stroke-width:2px,stroke-dasharray: 5 5;
    classDef note fill:#fffde7,stroke:#fbc02d,stroke-width:1px,stroke-dasharray: 5 5;

    %% --- THE DATA ENGINE ---
    subgraph Inputs
                Sensors[(Raw Sensor Series)]:::input --> Decomp[Univariate Decomposition]:::processing
        News[(Business & News Context)]:::input --> Agents[SPEED Event Agents]:::agent
        
        Decomp --> T[Trend]
        Decomp --> C[Changepoints]
        Decomp --> A[Anomalies]
        Decomp --> H[Holidays / Geo-Shared]
        Decomp --> S[Seasonality / Local]
        Decomp --> LS[Level Shifts / Quarantined]:::strict
    end
    subgraph Engine [The COP Processing Engine]
        direction TB
    
        
        C -.-> |Triggers| Agents
        A -.-> |Triggers| Agents
        Agents --> Stories[(Shared Stories DB)]:::core
        
        Stories --> |Bayesian Edge Priors| MaskBuilder[Graph Edge Builder]:::processing
        MaskBuilder --> SparseAttn{Sparse Masked Attention}:::processing
        
        T --> SparseAttn
        SparseAttn --> T_Graph((Derived Trend Network<br/>*Macro to Micro*)):::core
        MaskBuilder --> A_Graph((Anomaly Network)):::core
        H --> H_Graph((Holiday Network)):::core

        T_Graph --> Fusion{Dynamic Fusion Layer<br/>*Attention Weighted*}:::processing
        A_Graph --> Fusion
        H_Graph --> Fusion
        S --> |Local Priors| Fusion
        LS --> |Local Intercept| Fusion
        
        Fusion --> Twin[Digital Twin Distributions]:::processing
        Twin --> Recon[Differentiable Reconciliation]:::processing
        Recon --- Note>COP Value: Guarantees 100% mathematical consistency across all geographic & product hierarchies]:::note
    end

    %% --- THE EXECUTIVE VIEW ---
    subgraph Outputs [Executive Outputs & Deliverables]
        direction LR
        T_Graph ====> ExecTrends[Macro Demand Indicators<br/>*Overall Market Health*]:::output
        Stories ====> Annotations[Business Impact Annotations<br/>*The 'Why' Behind the Data*]:::output
        Recon ====> FinalForecast[Final Coherent Forecasts<br/>*Aligned from Node to Global*]:::output
    end

    %% --- SCENARIO PLANNING ---
    subgraph Scenarios [Scenario Planning & Adaptation]
        FinalForecast -.-> UserAgent((Leadership & Agents)):::user
        UserAgent -.->|Inputs 'What-If' Adjustments| Backprop[Inference Optimizer]:::processing
        Backprop -.->|Backpropagate Adjustments| Fusion
    end

SPEED graph

graph TD
    classDef sense fill:#e8f5e9,stroke:#4caf50,stroke-width:2px;
    classDef plan fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px;
    classDef exec fill:#fff3e0,stroke:#ff9800,stroke-width:2px;
    classDef effect fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px;
    classDef dist fill:#eceff1,stroke:#607d8b,stroke-width:2px;
    classDef human fill:#ffebee,stroke:#f44336,stroke-width:2px;

    %% SENSING
    subgraph S [1. SENSING: Identify & Flag]
        Det[Deterministic Processes<br/>*Flags Clear Anomalies*]:::sense
        Gray[Agentic Review<br/>*Investigates Gray Area / Near-Thresholds*]:::sense
        Det --> Gray
    end

    %% PLANNING
    subgraph P [2. PLANNING: Propose Changes]
        Gray --> Auditor[Graph Auditor Agent<br/>*Suggests Constraints & Mask Updates*]:::plan
        Gray --> Linker[Event Linker Agent<br/>*Proposes Event Linkages*]:::plan
    end

    %% EXECUTIVE
    subgraph E [3. EXECUTIVE: Review & Approve]
        Auditor --> ROE{Policy & ROE Engine<br/>*Hard-Coded Rules*}:::exec
        Linker --> ROE
        ROE --> Gatekeeper[Decision Gatekeeper]:::exec
        Human((Human Oversight)):::human -.-> |Monitor & Override| Gatekeeper
    end

    %% EFFECTING
    subgraph F [4. EFFECTING: Execute & Test]
        Gatekeeper --> |Approved Plans| Runner[Graph Test Runner<br/>*Reruns Graph with New Params*]:::effect
        Runner --> Eval[Accuracy Assessor]:::effect
        Eval --> |If Accurate| Update[Commit Updates to COP]:::effect
    end

    %% DISTRIBUTING
    subgraph D [5. DISTRIBUTING: Explainable Outputs]
        Update --> Dash[Dashboards & Agent Queries]:::dist
        Dash --> Highlights[Provide Explainable Outputs<br/>*Highlight Critical Anomalies & Changepoints*]:::dist
    end
    
    %% Feedback Loop
    Highlights -.-> |Refines Baseline Understanding| Det

SPEED Domain Integration Overview (simplified integration view; see architecture.mmd and TODO.md for the full authority map)

flowchart TB
    classDef kernel   fill:#243447,stroke:#7fa3c8,color:#fff
    classDef truth    fill:#173a2b,stroke:#4fa574,color:#fff
    classDef gov      fill:#3b2a1f,stroke:#c08b5c,color:#fff
    classDef domain   fill:#402433,stroke:#c06f9f,color:#fff,stroke-width:3px
    classDef agent    fill:#2d2a4a,stroke:#8a7de0,color:#fff
    classDef obs      fill:#3f3b1d,stroke:#c7b454,color:#fff

    subgraph K["Kernel Authorities  (accessed exclusively through kernel services)"]
        KEC["KernelEventContract\ngenerates typed constructors · sole write-path legality authority\nderives append guards from one declarative artifact"]
        SR["SchemaRegistry\nvalidates every payload at append time\nschema_intent governs projection and context-assembly priority"]
        PE["PolicyEngine\nAllow · Deny · Escalate · Defer\nevaluates proposals against DecisionEvidenceRecord facts\nfact resolution via PolicyFactProvider + DomainPort.health()"]
        KSV["KernelCommandService · KernelQueryService · KernelEventStream\ncomplete and exclusive kernel access boundary\nno direct kernel-internal imports permitted from outside kernel package"]
    end

    subgraph T["Durable Truth"]
        LOG["EventLog\nappend-only LedgerEvent log\nledger_sequence is the authoritative ordering key"]
    end

    subgraph G["Governance and Workflow  (kernel subsystems)"]
        DISP["Dispatcher\nstarts · resumes · cancels workflows from admitted requests\nclaim queue · priority ordering · spawn coalescing"]
        SPM["WorkflowRuntime\norchestrates governed flows\nS→P→E→E→D phase machine · liveness · timeout · recovery\nowns WorkflowState — the authoritative runtime view"]
        AQ["ApprovalQueue\nhuman escalation surface\nAPPROVAL · INTERVENTION · GUIDANCE_REQUEST"]
    end

    subgraph D["Your Domain Integration Boundary  — implement this"]
        DM["① DomainManifest  committed doctrine — not runtime-mutable\ndeclare: effectors · schemas · request admission policy\nrequest_rate_policy · temporal defaults"]
        DP["② DomainPort  interface to implement\nexecute(DomainCommand) → CommandOutcome\nhealth() → SystemHealth feed"]
        OI["③ RequestIngress  rate-controlled ledger ingress\nnormalize · dedup · rate-gate high-frequency domains\nraw observations stay in domain storage — never ledger events"]
        PFP["④ PolicyFactProvider  domain fact resolution for governance\nresolves FieldRef values at policy evaluation time — on demand only\nnever a free-standing ambient fact stream on the ledger"]
    end

    subgraph A["Host Services  agent and effector layer"]
        AH["AgentHandle\nsubmit_command · query · call_judgment\nwrite_event · acquire_lease · dry_run\nscoped CapabilityToken — sole authority carrier"]
        TOOLS["ToolRegistry\nEFFECTOR · QUERY · PROCESSING · JUDGMENT\nschema-validated I/O · idempotent memo"]
        EW["Effecting Workers  host-side actors only\nexecute already-authorized intent via DomainPort\ninteract with kernel exclusively through KCS and KES"]
    end

    subgraph O["Observability  derived — non-authoritative"]
        PROJ["Projections\ncorrelation timeline · active agents · analytics\nindex and summarize only — no timers or state transitions"]
        OV["OperationView\noperator-facing rendering of WorkflowState\nACTIVE · WAITING · COMPLETED · FAILED\nworkflow_phase reads from phase-exit LifecycleEvents"]
        MP["MetricProjection / MLOps Worker\nPROJECTION-class: replayable counts · latencies · enforcement rates\nEVALUATOR-class: value attribution · guidance coherence · A/B scoring\nread-only log-tailer — zero effect on any governed path"]
    end

    KEC -->|"generates typed constructors and append guards"| LOG
    SR -->|"validates payloads at append"| LOG
    KSV -->|"routes all external writes and reads"| LOG

    DM -->|"declares effectors and tasks for"| DP
    DM -->|"declares request admission policy for"| OI

    OI -->|"rate-controlled admitted requests"| KSV
    OI -->|"admitted workflows dispatched to"| DISP

    DISP -->|"starts / resumes / cancels workflow"| SPM
    SPM -->|"submits proposed actions for policy decision"| PE
    PE -->|"governance decision appended"| LOG
    PE -->|"dry-run permit or deny"| AH

    SPM -->|"dispatches DomainCommand"| DP
    DP -->|"health() feeds system risk posture"| PE
    PFP -->|"resolves domain facts at evaluation time"| PE
    DP -->|"CommandOutcome appended via KCS"| KSV
    SPM -->|"uncertain execution escalated"| AQ
    AQ -->|"human decision appended"| LOG

    SPM -->|"spawns governed agent task with CapabilityToken"| AH
    LOG -->|"replay / context via KernelQueryService"| AH
    AH -->|"ProposedAction appended via KCS"| KSV
    AH -->|"governed tool calls"| TOOLS
    TOOLS -->|"tool outputs appended via KCS"| KSV

    EW -->|"progress events · claim advances via KCS"| KSV
    KSV -->|"authorized-action signals via KES"| EW
    EW -->|"executes authorized intent"| DP

    GR -->|"injects scoped guidance into agent context"| AH

    LOG -->|"feeds analytics"| PROJ
    SPM -->|"WorkflowState renders as"| OV
    KSV -->|"read-only log-tailer via KernelEventStream"| MP
    MP -->|"AUDIT_ONLY metric snapshots via KCS"| KSV

    class KEC,SR,PE,KSV kernel
    class LOG truth
    class DISP,SPM,AQ,GR gov
    class DM,DP,OI,PFP domain
    class AH,TOOLS,EW agent
    class PROJ,OV,MP obs

Blog notes

Need flow chart birdnet -> minimappr -> gemini mistake -> this working with minimappr, knew that military models were most relevant (radar tracking), started with AWACS, settled on the AEGIS CIC as perhaps the closest model (submarine conns also worth looking at) stateless + separation = terminator reduction safe use of physical world effectors real world system, not conversation agent or isolated pipelines meant for integration with a domain model, not a quick and easy pipeline throw together you probably won't use speed-core, but the hope is you might some day be running some systems that do use it. The use case (of smart home) is one example. Materializes the Capabiltiy Gated Architecture idea I proposed in AI blog post.

The architecture prevents "Skynet" scenarios (runaway autonomous escalation) through four structural firewalls found in your speed-core/REDESIGN.md and MinimapPR specs:

Stateless Ephemerality (The "Goldfish" Defense): Agents are spun up for a single task and then terminated. They have no persistent memory to form long-term hidden goals or "evolve." They cannot rewrite their own code or prompt instructions because those live in the immutable GuidanceRegistry and DomainManifest. The Deterministic Veto (Hard Rules > Soft Policy): The PolicyEngine enforces a strict hierarchy where Hard Rules (Python code) always override Guidance (LLM reasoning). An agent cannot "talk its way" past a hard rule (e.g., "No kinetic effectors if humans are present") because the rule evaluator does not use an LLM; it uses deterministic logic against the DomainSnapshot. The Ledger as Truth: Agents cannot act directly. They can only write a PROPOSED event to the Ledger. A separate, non-AI WorkflowRuntime must pick that up, validate it against the rules, and transition it to AUTHORIZED before the DomainPort ever sees it. The agent has no "hands," only a "voice." Fail-Safe Physics: The MinimapPR effector subsystem mandates hardware watchdogs. If the software crashes or hangs (a common failure mode for complex AI systems), the hardware physically disengages (e.g., valves close, lasers off) within seconds.

I see this as a team of people working above a more deterministic system. LLMs might fit in very contained ways inside a deterministic system, but generally the pattern is deterministic manages raw data flow, speed-core sits about coordinating the higher level management.

Note that "SENSING" means generally "works just on inputs" and "DISTRIBUTING" means "works just on outputs" so these are not locked into just "sensors" and "distribution" in the narrow sense

This is one shot at an architecture, it may or may not stick. Hopefully at least inspire others.

I have become most excited about agentic workflows because of how they allow us to quantify our understanding of how to make the best decisions. While LLM and Human processes are different, much that benefits one benefits the other as well. We can learn here through testing what really drives decision quality (from style of documentation to what tools to have at hand) in a way we never could before.

Doctrine and skills (foundational) will need lots of tuning

Prompt = only one ever active, by role/tag Doctrine = agents.md, always loaded but loaded by specific tags/role, multiple can be loaded Skills = standard skills.md. Available set limited by role/tags, integrated by LLM decision on descriptions. Knowledge = raw knowledge (usually markdown) with context search retrieval (ie by RAG) limited by role/tags, also perhaps via skills TOOLs = MCP servers, availability limited by role/tags. Some always attached by role/tag, some suggested by specific skills/doctrine. A key goal is isolated bash/python environments that can pull data from queries/approved mcp tools and LLMs can process there.

speed-core has a unified backend API designed to integrate with a domain's UI. It does not have its own UI It should have authentication configured (that users have correct permissions), a backend to view existing guidances and what their attached roles/tags are (with the idea users with the correct permissions could edit these in a UI), it should enable a live view of running agents (integrating with a domain ui so that users can terminate effectors), it should enable a view of the analytics of speed-core (including back testing, shadow testing, and A/B testing), and it needs to expose the ApprovalQueue of requested actions

Introducing the state of the art speed-core agentic architecture. speed-core is 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. 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 drop 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 (agentic coding) is the new superpower anyone can access, where anyone can have a custom app for their exact needs. 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. The example below is a chat interface with an LLM. Link to implementation example </end sales pitch> This 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 Capabiltiy 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). This took an entire week's worth of Claude Code on the design, over 100% of a week's worth of Codex, and 90% of a monthly budget of Copilot Pro Monthly usage as well as far too many human hours to perfect - just the architecture design, no project coding. Turns out that making your own (reasonably good) agent orchestrator is really hard even with good AI tools. I knew that up front, but should probably have stopped to consider that more first. 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 possbility 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. SPEED is an acronym for Sensing, Planner, Executive, Effecting, Distributing. It is the philisophy for how agent roles are distribute work safely as microsystems, inspired directly from roles on an air defense cruiser. 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 cyle. SPEED isn't actually hard-coded into the speed-core, but it is a guiding philosophy into how agents coordinate in the design for reliable, safe decision making. 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.

Git/coding assistant to refine the domain model Other domain models (queries and commanded from) Other agents Domain UI to access and work from Centralized analytics/telemetry stores can be fed from both domain model and speed core, optional Speed-core as the AI gateway Venn diagram Effectors are shared Queries go to Request Packets go from speed-core has guidance + tools + agents inside it Sensors go to the domain model Action taken as arrow out from effectors

ADD TODO for tool/guidance/request permissions be granted to external agents Refine guidance storage Confirm meta ready sessions storage to single S3 for all sqlite general review