Subnet345

Manifesto · the agent era

What an agent actually is.

Most software being called an agent today is not one. The word has been generalized into uselessness. This page is what Subnet345 means when we say it, and how we build for what we mean.

Document ∷ agents.0001Revision ∷ 2026.05Authority ∷ Practice leadRead ∷ Operator
01
The era

The era is real, and the regulatory floor is rising.

Multi-agent systems are coordinating production work today. AI agents moved from pilot to production faster than any previous enterprise technology cycle. The transition happened faster than enterprise governance prepared for.

Existing frameworks (SR 11-7 for model risk, EU AI Act for high-risk systems, DORA for operational resilience) point at a single expectation: AI-driven decisions must be explainable, governed, reviewable, and attributable. The frameworks are converging on that expectation. Most deployments are not.

The first CISO to face a regulator inquiry about an autonomous agent decision will either have a governed, replayable record, or will not. That outcome is decided in the months before the inquiry arrives, not when it does.

02
Definition

What an agent is. And what an agent is not.

An agent is goal-directed, stateful software that operates over time. It plans. It executes. It hands off to other agents or to humans. It recovers from failure. It maintains state across sessions. It uses tools. These are the load-bearing properties, not optional features.

An agent is not a chatbot with prompts wrapped around it. It is not a retrieval-augmented language model. It is not a function call with branches. It is not a workflow engine relabeled. Software marketed as an agent without the load-bearing properties is software marketed misleadingly.

The distinction matters because the operational obligations are different. You can lose a chatbot conversation without consequence. You cannot lose an agent decision without consequence.

03
Properties

Three properties separate agents that survive production from demos that do not.

Memory. Agents need durable context across sessions. State that lives inside a single vendor's API does not survive a vendor change or an audit request. State that lives inside your boundary does. Memory is the precondition for accountability.

Accountability. Every action an agent takes, every handoff it makes, every decision it produces must leave a reviewable record. The record is not optional metadata for a future audit. It is the substrate that makes the agent operable in regulated environments at all.

Coordination. Single agents are easy. Multi-agent systems require explicit handoff semantics, visible authority chains, and a way for one agent to recover when another fails. Most production agent deployments today have none of this. They will need it. Sooner than expected.

These are not three features to bolt on. They are three properties to design around. Substrate decisions made early either accommodate them or rule them out.

04
Posture

Agents are teammates, not tools.

The most consequential design decision an organization makes about agent systems is the metaphor it builds them under. The dominant metaphor today is the function call. Software calls software. Inputs become outputs. The agent is treated as ephemeral, replaceable, stateless.

A teammate is the opposite. A teammate has memory of past work, a place on the org chart, an audit trail on their decisions, and a way to hand off to a human or another teammate. Production agent systems that survive treat agents this way. Demo agents treat them as function calls and break the moment the deployment leaves the demo environment.

The substrate beneath the agents either supports the teammate metaphor or forces the function-call one. We build for the teammate metaphor. The properties in tenet 03 are how that metaphor becomes operable.

05
Substrate

Where agents run determines what they can be.

An agent's substrate decides what it can become. Memory location, decision audit, vendor leverage, regulatory posture: all of these are determined by where the agent and its history actually live. Substrate choice is one of the few decisions in an agent program that compounds, in either direction, from day one.

Two paths support governed agents. Private AI infrastructure keeps the entire decision lifecycle inside your boundary, on hardware you operate. Negotiated model-provider arrangements keep it under contractual terms that survive vendor changes, with data residency, retention, and audit access agreed up front. Both are governed. Default public-API access without negotiated terms is not. The substrate decision is which governed path fits your engagement, not whether one is needed.

Speed differs by path. If your organization has the governance work already in place, your agent swarm initializes inside your environment on the first scheduled engagement business day. If you are building the substrate for the first time, the timeline extends to match the build. We work in both modes, and we tell you which one applies at scoping.

If your organization is ready, we ship on day one.

How we build for this

Our practice is built around these tenets. Our open contributions are the substrate-level receipts.

yaklog is our open-source AI coordination layer. spectra is our open-source firewall evaluation tool for the cybersecurity lane. The Practice page describes the three lanes we work in. The Industries pages describe how the tenets adapt per sector.

If these tenets describe the agents you want to build

Talk to an operator.

Submit an inquiry →