Independent engineering and applied AI research focused on building agentic systems that survive contact with the real world.

ForgeWire Labs is an independent engineering and applied AI research lab founded by Jeremy Shows.

I build systems around a central question:

How do we make AI-assisted systems genuinely useful when models are fallible, infrastructure is imperfect, resources are limited, and deployment conditions keep changing?

ForgeWire began as an attempt to build a better personal AI system. It has grown into a modular architecture for coordinating models, agents, tools, memory, knowledge, compute, and distributed execution.

The work combines production engineering with longer-term research into recurrent reasoning, continual learning, adaptive routing, calibrated fusion, persistent agency, and human-directed automation.

ForgeWire Labs is where those ideas become working systems.

Agentic systems are systems first and models second.

Survivability under deployment, through graceful degradation, layered ownership, parity paths, audit trails, and replaceable substrates, is the property that determines whether they are useful, not benchmark scores on a model card.

A capable model can still be part of an unreliable system.

Models can be wrong, slow, expensive, unavailable, deprecated, or replaced. Providers change. Dependencies fail. Hardware becomes constrained. Requirements evolve. An agentic system becomes genuinely useful only when the architecture surrounding its models can survive those conditions.

ForgeWire therefore treats a model as one replaceable component within a larger system for intelligent work.

That system must provide:

• graceful degradation when components or services fail
• explicit ownership and responsibility boundaries
• portable and accelerated paths with tested behavioral parity
• durable audit trails connecting intent, execution, and outcome
• replaceable models, providers, transports, storage layers, and compute substrates
• observable state and recoverable execution
• policy boundaries for tools, agents, and remote runners
• evaluation based on deployed behavior rather than isolated demonstrations

Benchmarks matter, but they are diagnostic rather than definitive. Model quality matters, but model quality alone does not produce a dependable agentic system.

ForgeWire is built around the machinery that allows intelligence to remain useful after it encounters the real world.

ForgeWire is a modular architecture for building, operating, and evolving agentic systems.

It coordinates:

• models and providers
• personas and specialized agents
• tools, skills, and permissions
• memory and knowledge
• task decomposition and execution
• local and remote compute
• structured events and messaging
• policy and human approval
• checkpoints, replay, and recovery
• evaluation, telemetry, and audit
• desktop and service interfaces

ForgeWire is not a single chatbot, model wrapper, or autonomous agent.

It is the surrounding system: the services, protocols, boundaries, state, control paths, fallback mechanisms, and operational records required to turn model capability into dependable work.

The architecture is intentionally modular. Models, providers, stores, transports, dispatchers, interfaces, and execution substrates should be replaceable without requiring the entire system to be rebuilt around them.

ForgeWire is composed of specialized layers that can operate independently while participating in a larger coordinated system.

ForgeCore is ForgeWire's portable execution substrate.

It provides foundational runtime behavior without depending on the larger application. Its boundaries are deliberately narrow so it can remain liftable, testable, and replaceable.

ForgeCore includes work related to:

• work-graph execution
• task dispatch
• capability and policy enforcement
• runtime coordination
• Python and native execution paths
• parity validation
• compute selection
• controlled acceleration
• structured execution results

The substrate exists as a leaf rather than as an inseparable center of the application. That boundary is part of the thesis expressed in code.

ForgeWire Fabric is the distributed execution and control-plane layer.

Fabric allows authenticated work to move across machines while preserving explicit authority, policy, provenance, and execution history.

Its responsibilities include:

• signed task dispatch
• scope-bound capability tokens
• policy-gated runners
• authenticated coordination
• structured event streams
• distributed task state
• runner registration and discovery
• audit and replay boundaries
• federated transport
• control-plane resilience

Fabric extends ForgeWire beyond one process or machine without treating remote execution as implicit trust.

ForgeWire Bus is the communication substrate connecting services, agents, runners, and execution environments.

It supports structured events, transport abstraction, persistence boundaries, and local or distributed messaging without forcing the rest of the system to depend on one broker.

ForgeWire Loom coordinates execution environments and exposes ForgeWire capabilities to agent and developer tooling.

It participates in the boundary between requested work and the services capable of performing it.

Above the substrate are the services that make ForgeWire useful as an integrated system:

• provider and model management
• personas, agents, tools, and skills
• conversations and content
• memory and knowledge
• jobs and scheduled work
• task routing and decomposition
• policy and approval
• speech and multimodal services
• desktop, API, CLI, and automation interfaces

Each layer has a defined responsibility. Capability should emerge from their coordination rather than accumulate inside one oversized agent.

Most AI products optimize for the immediate interaction between a user and a model.

ForgeWire addresses the larger problem.

A useful agentic system must continue functioning when:

• its preferred provider is unavailable
• a model produces an invalid result
• an optional dependency is missing
• hardware resources are limited
• a fast implementation cannot be used
• execution moves to another machine
• an agent exceeds its permitted scope
• state must survive process failure
• behavior must be reconstructed later
• the architecture evolves without losing operational continuity

These are not edge concerns. They are the conditions under which software actually operates.

ForgeWire exists to investigate and build the system around the model: the part responsible for continuity, coordination, authority, recovery, evaluation, and trust.

The behavior of the whole system matters more than the apparent intelligence of one component.

A feature is not complete because it works once. It must remain understandable and recoverable across failure, change, and constrained deployment.

Optional services and accelerated paths must not become hidden single points of failure. Portable fallback behavior is a first-class architectural concern.

When ForgeWire provides fast and portable implementations of the same capability, their contracts must remain aligned and testable.

Responsibility is defined across components, repositories, agents, and execution scopes. Ownership boundaries are part of how the system operates.

Documentation, implementation, tests, events, and operational state must remain connected closely enough to reconstruct what the system believed and did.

No model, provider, transport, database, runtime, or accelerator should become synonymous with the system itself.

Agents receive capabilities through explicit scopes, policies, and execution boundaries. Intelligence does not automatically grant authority.

Experimental ideas remain separate until they demonstrate useful behavior without weakening the production system's guarantees.

A self-hosted control plane for authenticated and auditable remote task execution.

Fabric is currently the primary public window into ForgeWire's systems-first engineering. It demonstrates how work can move across machines through explicit protocols rather than informal agent trust.

Current areas include:

• signed dispatch envelopes
• capability-aware runners
• structured task events
• policy enforcement
• Python and Rust parity
• distributed persistence
• audit and replay
• federated transport
• developer-tool integration

Fabric is one component of the larger ForgeWire architecture, not the entirety of ForgeWire.

An offline-capable certification learning and exam-preparation platform.

The first curriculum targets CompTIA A+ and is being designed around:

• structured certification objectives
• original practice questions
• performance-based questions
• mock examinations
• flashcards and spaced repetition
• readiness analytics
• notes and search
• local progress storage
• encrypted backups

SkillForge Academy is a ForgeWire Labs product rather than a subsystem of ForgeWire. It reflects the lab's broader interest in practical software that helps people develop real capability.

An earlier multi-agent assistant platform and an important part of ForgeWire's engineering lineage.

SCOUT explored model coordination, personas, tools, retrieval, speech, background work, messaging, and desktop AI interaction. Its successes and architectural limitations helped reveal the systems problems that ForgeWire was created to address.

SCOUT-2 remains public as a record of that evolution.

ForgeWire Labs also investigates ideas that may eventually extend the production architecture.

Experimental work is not presented as finished capability. It must be implemented, measured, compared against baselines, and introduced through controlled boundaries before becoming part of ForgeWire.

This work investigates bounded recurrent processing for tasks that benefit from revision, comparison, refinement, and evaluation.

The objective is not to create unrestricted reasoning loops. It is to develop task-local control that can decide when another pass is useful while preserving explicit limits and observable state.

Research areas include:

• bounded reasoning passes
• recurrent task state
• confidence and drift signals
• controlled route histories
• task-local checkpoints
• observe-only controllers
• measurable stopping conditions
• privacy-conscious telemetry
• canary-gated adaptation

ForgeWire Labs explores how systems can retain useful experience without uncontrolled drift or catastrophic forgetting.

This includes:

• replay and evaluation
• specialist routing
• adaptive caches
• confuser-focused training
• calibrated fusion
• provenance-aware updates
• function-preserving growth
• operational measures of adaptation and regret

ForgeWire maintains a deliberate boundary between speculative architecture and operational capability.

A research component must pass through stages such as:

1. conceptual framing
2. isolated implementation
3. baseline comparison
4. controlled evaluation
5. replay and failure analysis
6. observe-only integration
7. limited canary deployment
8. production gating

This process allows ambitious ideas to be explored without allowing them to weaken the system that already works.

Research is valuable when it produces clearer questions, measurable behavior, reusable components, or better architecture. It does not need to become a product feature to have succeeded.

ForgeWire is also being used to help build ForgeWire.

The repository contains structured instructions, ownership boundaries, audits, roadmaps, task state, validation scripts, and scoped operational memory that allow coding agents to work within defined areas of responsibility.

Agents can:

• locate the rules governing their scope
• inspect prior decisions and audits
• perform bounded implementation work
• run appropriate validation
• update project state
• preserve useful context for later work
• escalate when a decision exceeds their authority

This makes the repository more than a place where source code is stored. It is part of the operating environment through which humans and constrained agents coordinate development.

ForgeWire does not assume that agents are reliable merely because they are capable. It builds the controls, records, and recovery paths needed to use them responsibly.

ForgeWire emerged through several generations of assistants, orchestration experiments, communication systems, and cognitive architecture research.

The broad lineage is:

SCOUT → SCOUT-2 → SCOUT-3 → ATLAS → PhrenForge → ForgeWire

Each generation exposed limitations in the previous approach:

• monolithic assistants gave way to modular services
• prompts gave way to personas, tools, skills, and permissions
• implicit coordination gave way to structured events
• direct execution gave way to policy and capability boundaries
• single-machine assumptions gave way to authenticated distributed work
• fragile acceleration gave way to tested parity paths
• scattered project context gave way to repo-native memory and governance
• speculative cognitive components gave way to gated research programs
• model-centered design gave way to systems-first architecture

The current ForgeWire thesis was not chosen as branding. It was extracted from the failure modes and design constraints encountered across those rewrites.

Implementations will continue to change. The thesis is intended to survive them.

I am a self-taught engineer and independent researcher with a background spanning mechanical work, electrical systems, low-level hardware repair, race-car engineering, fabrication, construction, small-business ownership, and information technology.

That history shapes how I approach software.

I tend to see AI systems as machinery: assemblies of components with interfaces, tolerances, failure modes, feedback paths, and operational limits. A convincing demonstration is not enough. The system must still work when a component fails, hardware is limited, requirements change, or an automated process exceeds its authority.

My work crosses:

• distributed systems
• agent infrastructure
• applied machine learning
• developer tooling
• desktop software
• technical education
• cognitive architecture
• neuroscience-inspired computation
• security and policy boundaries
• evaluation and automation

I am not approaching these subjects from a single academic discipline or conventional career path. ForgeWire Labs grew from repeatedly learning what was necessary to build the next part, testing it, discovering where it failed, and rebuilding it with stronger boundaries.

ForgeWire Labs is the home for that work.

ForgeWire is developed as an integrated private system. Stable components and products are released publicly as their contracts, documentation, tests, security boundaries, and operational behavior mature.

Public releases are intended to include enough context to be evaluated seriously:

• architecture and design documentation
• tests and validation evidence
• security and authority boundaries
• changelogs and migration guidance
• known limitations
• operational instructions
• separation between production and experimental work

• ForgeWire Fabric: validation, documentation, and public release hardening
• SkillForge Academy: offline-capable certification learning
• SCOUT-2: historical foundation and architectural lineage

• ForgeWire core integration
• ForgeCore runtime and compute substrate
• Fabric control-plane development
• knowledge and memory productization
• evaluation and benchmarking
• repository-native agent operations
• recurrent cognitive control planning
• routing, fusion, and continual-learning experiments

ForgeWire Labs currently works primarily with:

Rust · Python · TypeScript · React · Tauri · GTK · SQLite · rqlite · PostgreSQL · PowerShell · GitHub Actions

Technology is selected according to the role it serves.

ForgeWire is not organized around promoting a particular language, framework, model provider, database, accelerator, or cloud platform. Those are implementation choices within the system, not the identity of the system.

ForgeWire Labs is an independent, founder-led lab under active development.

Some systems are public. Others remain private while their architecture and release boundaries are stabilized. Research programs are identified separately from production capabilities.

The work is ambitious, but its standard is practical:

Agentic systems are systems first and models second.

Build the whole system. Test it under failure. Preserve its history. Keep its parts replaceable. Make its authority explicit.

Then determine whether it is useful.