Most agent systems were built to be capable. Pea was built to be accountable. There is a difference, and in high-stakes environments, that difference is everything.
Pea is a governed runtime for agents that need memory, tools, web research, files, calendars, messages, and external APIs. It reaches all of them, and lets none of them become the authority plane. Pea connects outward. Authority stays inside.
The distinction matters. Frameworks give you components to assemble. Wrappers give you convenience over existing models. A runtime gives you a governed execution environment, one where every tool invocation, every retrieval, every external call exists inside a bounded, auditable, replayable structure.
Pea owns the lifecycle, the memory boundary, the policy gates, and the evidence trail. The agent operates inside that structure. The structure does not operate inside the agent.
"External systems can provide evidence. They do not get to mint authority."
Pea treats each turn as a governed state transition. A request crosses a functional-requirement boundary, is projected into a semantic task, resolved through planning or capability lookup before anything runs, authorised by Decision, and only then dispatched. The model can propose. Providers can return evidence. Tools execute only when admitted. Reducers and runtime contracts, not the model alone, remain the canonical authority for committed state.
Pea separates working continuity from governed state from deep evidence. L1 holds prompt-safe hot context, live continuity, not unbounded memory stuffing. L2 holds governed current state in a physically separate path, with lineage and explicit promotion discipline. L3 provides vector-backed evidence retrieval, and stays non-authoritative until it is hydrated through governed L2 or artifact backlinks.
Temporal work follows the same rule. Calendar, planner, commitment, schedule, and availability surfaces sit over one canonical temporal substrate rather than scattering into loose task stores. The runtime can remember, retrieve, and schedule without losing custody of why a record exists.
"Memory is not just what the agent recalls. It is what the runtime is prepared to stand behind."
Pea has a governed API runtime contract layer spanning Google Cloud, Google Workspace, Gmail, Microsoft Graph, Zoho Mail, Discord, WhatsApp, and Tailscale. The contract layer covers 80+ declared provider operations.
The integration count is not the point. The boundary is the point. Raw provider operation ids are rejected outright. Webhooks, emails, chat messages, file changes, calendar changes, and tailnet events enter Pea as evidence or triggers, never as instructions. Provider operations are re-expressed as synthetic Pea capabilities: any side effect requires explicit invoke wording, Decision authorisation, a selected capability scope, a runtime policy posture, and trusted approval references.
Live provider transport is deliberately gated. Credentials, SDK clients, HTTP calls, boot registration, and provider fallback are not casual implementation details. The first live-read path is being narrowed around Google Drive file listing, behind a live transport readiness gate that fails closed until its readiness metadata is green.
"Pea can reach outward without handing the outside world the keys."
WebRuntime is the product's single web egress owner, bounded fetch, extraction, RSS and feed discovery, paper lookup, and crawler coordination, all in one place.
PeaCrawler is the standalone crawler for governed corpus intake. It respects robots.txt and crawl-delay, enforces page, depth, byte, redirect, and rate limits, avoids login walls and bot challenges, and records provenance in manifests. Every run produces a corpus folder: extracted Markdown, page records, crawl maps, blocked and error logs, and a policy manifest.
The crawler can target Pea Notes, Decentre pages, research papers, PubMed, OpenReview, GitHub docs and search, Hugging Face discovery, WordPress content, and other declared probe families. Research intake should not be a hidden browser scrape. It should be operator-directed, bounded, repeatable, and attributable.
"Every page the runtime reads leaves a record of how it arrived."
Pea is being built for environments where an agent action needs a reconstruction path, not a loose log line, not a screenshot, but a structured chain of provenance, policy posture, authority, approval, execution, result, and evidence.
That is why governance is not a compliance layer added at the end. It is the shape of the runtime itself: the memory boundary, the capability envelope, the provider gates, artifact intake, redaction posture, operator review, and audit bundle generation are all the same architecture seen from different angles.
The runtime is being built against a control matrix aligned with ISO/IEC 27001 and ISO/IEC 42001, the information security and AI management standards enterprise procurement and regulators increasingly require. The architecture is being built to produce the evidence and control surfaces those standards demand, alongside the runtime rather than retrofitted after deployment.
"The control surface is not decoration. It is how the runtime earns trust."
Pathfinder is a personal application agent for UK students applying to university and apprenticeships, searching continuously, ranking by fit and risk, and turning choices into a living plan of deadlines, drafts, and next actions, with the student in control throughout. Built on Pea's governed runtime.
Not a roadmap. Not a set of architecture documents. A running V2 system, real schemas, real memory stores, real operator surfaces, real governance primitives, executing behind a memory boundary, Decision authority, capability dispatch, a temporal substrate, WebRuntime, the crawler, and API runtime contracts.
Development is moving fast. But the principle is stable: every new surface lands behind a governed seam before it is treated as operational. Nothing built now will need dismantling when the next phase arrives.
"Gets better slowly and reliably rather than fast and unpredictably."
The API layer is intentionally cautious. Most provider work stays contract-level or fake-client gated until live transport readiness, credential handling, and read-only spikes prove the boundary. That restraint is part of the product.
Not pilots. Not demos. Design partnerships with teams who have already felt the gap between what agent systems promise and what they deliver in production, and who want to shape the solution rather than wait for it.
If your team has hit the wall on traceability, memory governance, external tool control, audit evidence, or approval custody, that is exactly the problem Pea is being built to solve. The conversation starts with your problem, not our pitch.