AIBYS Agentic Operations Platform
A 10+ agent Hermes environment with specialised profiles across engineering, operations, intelligence, creative work, revenue, and governance — with a verified subset integrated through one authenticated control plane carrying human approval gates and an append-only record of everything that happened.
01Overview
AIBYS operates a 10+ agent Hermes environment with specialised profiles across engineering, operations, intelligence, creative work, revenue, and governance. The AIBYS Command Center is the control plane over it: one authenticated place to dispatch missions, watch them execute in real time, approve or reject what they produce, and read back a complete audit trail. The current Command Center integration exposes a smaller verified subset of that environment through its authenticated bridge — deliberately, because a profile is only listed as integrated once the bridge handshake confirms it. Hermes remains an independent execution engine behind a replaceable adapter, so the control plane governs the work without being welded to the runtime that performs it.
02Problem
Running more than one or two agents stops being a prompting problem and becomes an operations problem. Work is dispatched and then invisible. Nobody can say which agent did what, on whose authority, or against which model. There is no way to stop a run that has gone wrong, no gate before something consequential is sent, and — most corrosive of all — no reliable distinction between a result produced by a real execution and one produced by a test harness. Without that distinction, every other guarantee is decorative.
03David's role
- Sole architect and engineer: domain model, state machines, event store, adapter contract, transport protocol, authentication, operator interface, deployment, and runbooks.
- Designed the neutral adapter contract so Hermes, and later other engines, sit behind a replaceable interface rather than being coupled into the application.
- Specified and built Bridge Protocol v1 — the authenticated, outbound-only transport that connects the control plane to the agent runtime.
- Implemented the authentication layer end to end and gated deployment on it: the system was explicitly marked do-not-deploy until authentication existed.
- Wrote the operations, security, and recovery documentation, and the architecture decision records that justify each structural choice.
04Architecture
Seven layers, each with one job and a defined contract to its neighbours. A human operator works through the command centre; the approval layer gates anything consequential; specialised agents hold roles and isolated profiles; the runtime layer executes against model providers; tools, MCP, and integrations expose capability; business systems are the systems of record; and an evidence layer captures everything that happened, append-only, underneath all of it.
- 01
Human / Executive
Dispatches missions, holds authority, decides anything consequential
- 02
Command Center / Approval Layer
Authenticated control plane · mission lifecycle · approval gates · cancel, suspend, kill
- 03
Specialised Agents
A 10+ profile Hermes environment spanning engineering, operations, intelligence, creative work, revenue, and governance — distinct roles, isolated profiles, scoped tool access
Integrated through the authenticated bridge
- JarvisOrchestration
- Iron ManEngineering
- NatashaIntelligence
- WandaWriting & brand
- VisionCreative
- TonyFast execution
Wider environment · Engineering · Operations · Intelligence · Creative work · Revenue · Governance
- Carol
- Maria
- Dr. Strange
- Clint
- Pepper
- Thor
- Rocket
- and others
- 04
Runtime / Model Layer
Hermes runtime behind a neutral adapter · authenticated bridge · executor verified at handshake
- 05
Tools / MCP / Integrations
Capability surface exposed to agents under per-agent permission boundaries
- 06
Business Systems
CRM, communications, calendars, documents, and revenue workflows — the systems of record
Evidence / Logging / Observability
Append-only event log · provenance on every record · audit trail · executive visibility
Captures every layer above it. UPDATE and DELETE are physically blocked at the storage layer, and every record carries whether it came from a live run, a simulation, or seed data.
05How it works
- 01
Dispatch
An operator launches a mission through a guided flow with an explicit confirmation step. The mission enters a lifecycle state machine with eleven states; any transition that is not legal raises rather than quietly corrupting state.
- 02
Route
The orchestrator agent decomposes the mission and routes it to the specialist whose role fits — engineering, research, writing, creative, or fast execution — each running under its own isolated profile with its own scoped tool access. Routing targets the profiles currently exposed through the bridge allowlist, not the whole environment.
- 03
Execute
The dispatch crosses the adapter into Bridge Protocol v1: an authenticated, outbound-only HTTP bridge running alongside the agent runtime. The bridge declares its executor in a handshake, and the adapter derives whether this run is genuinely live or simulated from that declaration rather than from configuration.
- 04
Observe
Progress, cost, and artifact events stream back over server-sent events into a live intelligence feed. Every event is appended to an immutable log, ingested idempotently so a retry cannot double-count.
- 05
Approve
Anything consequential stops at the approval console, where the operator sees the artifact itself and approves, rejects, or requests a revision. The runtime confirms the decision back, and late approvals reconcile correctly against missions that have already moved on.
- 06
Account
The mission completes with a full audit trail — who dispatched it, which agent ran it, what it produced, who approved it, what it cost, and whether it was live or simulated — surfaced in an executive dashboard.
06AI & technology
- Hermes agent runtime as the execution engine, reached through a neutral adapter contract rather than a direct dependency
- A 10+ profile Hermes environment spanning engineering, operations, intelligence, creative work, revenue, and governance, of which a verified subset is currently integrated through the bridge
- Specialist agent roles with isolated profiles, persistent shared context, and per-agent capability and skill definitions
- Multi-provider model architecture with routing modelled and validated in configuration
- Scheduled execution, liveness and timeout sweeps, and heartbeat-based agent health
- Server-sent events for real-time streaming of progress, cost, and artifact events
07Integrations
- Hermes runtime via Bridge Protocol v1 — authenticated, outbound-only, executor declared in a handshake
- Replaceable adapters specified for OpenClaw, Atlas, Codex, Claude Code, and n8n as independent execution engines
- SQLite in development on Node's built-in driver, with Postgres as the production target and canonical DDL maintained
- systemd service units with hardening, timers, log rotation, and a guarded deployment script with rollback
08Human control & governance
- Single-operator authentication: scrypt password hashing, HMAC-signed server-side sessions, HttpOnly / SameSite=Strict / Secure cookies
- Three independent fail-closed enforcement layers — edge middleware, route guards, and a layout gate — so no single miss exposes the surface
- Same-origin checks on every mutation, database-backed login rate limiting, and authentication events written to the audit log
- Append-only event store where UPDATE and DELETE are physically blocked, not merely discouraged
- Provenance labelling on every record and event — live, simulated, or seed — enforced at the storage layer
- Human approval gates with artifact preview; cancellation, agent suspension, and a kill switch that operate on in-flight work
- Services bound to loopback interfaces only, with public exposure gated behind a documented HTTPS and access checklist
09Key design decisions
The decision, the alternative it was chosen over, and why.
- 01
Decision
Make provenance a storage-layer invariant: every record and event carries whether it is live, simulated, or seed.
Instead of
Tracking simulation state in application code or trusting a configuration flag to describe the environment.
Why
A control plane that cannot distinguish a real execution from a harness run is worse than no control plane, because it launders test output into apparent fact. Pushing the label down to storage means no code path — including one I write later, in a hurry — can present simulated work as live. It also let the system be built and demonstrated honestly long before the runtime was connected.
- 02
Decision
Derive live-versus-simulated from the bridge's own executor handshake rather than from local configuration.
Instead of
A setting in the control plane that declares which mode it believes it is in.
Why
Configuration drifts and lies. Asking the thing on the other end of the connection what it actually is makes the answer self-correcting: point the bridge at a real runtime and the label changes on its own, and a misconfiguration downgrades to simulated instead of silently claiming to be real.
- 03
Decision
Physically block UPDATE and DELETE on the event store instead of relying on discipline.
Instead of
A conventional mutable table with a code-level rule not to rewrite history.
Why
An audit trail that can be edited is not an audit trail. Enforcing immutability in the storage layer means the guarantee survives every future contributor, every migration, and every incident where someone is tempted to tidy up the record. Corrections supersede; they never overwrite.
- 04
Decision
Treat the absence of authentication as a hard deployment gate, documented in the README as do-not-deploy.
Instead of
Deploying to a private network and adding authentication in a later phase.
Why
Private-network-for-now is how systems end up permanently exposed. Naming it as a blocking gate in the most-read file in the repository kept the constraint visible until it was actually resolved — and it was, before anything went public.
- 05
Decision
Put Hermes behind a neutral adapter contract with a registry, rather than integrating it directly.
Instead of
Calling the runtime from the application layer, which would have shipped sooner.
Why
The execution engine is the fastest-moving and least-controllable part of this system. Isolating it behind a contract means a runtime change is an adapter change, and it made a simulated harness a first-class implementation of the same interface — which is what allowed the entire vertical slice to be built and tested before the transport existed.
- 06
Decision
Expose agent profiles to the control plane through an explicit bridge allowlist rather than discovering whatever the environment happens to be running.
Instead of
Enumerating every profile present on the Hermes host and surfacing them all automatically.
Why
Auto-discovery would make the control plane's roster a function of whatever exists on the host at that moment, including half-configured and experimental profiles. An allowlist means a profile becomes dispatchable only once someone has decided it should be, which is why the integrated subset is smaller than the environment — and why every profile the Command Center will route to is one whose permissions and role were reviewed.
- 07
Decision
Ship a component-status table that marks parts of the system not implemented, configuration-only, or deliberately deferred.
Instead of
Describing the system by its intended capabilities.
Why
Overstated status is the most expensive mistake available in an agent platform, because every decision downstream inherits it. An explicit table of what is real, what is specified, and what is deferred is what makes the parts marked real worth believing.
10Tradeoffs
- SQLite on the built-in Node driver was chosen for development speed and zero operational overhead; Postgres remains the production target and the canonical schema is maintained ahead of the migration.
- Single-operator authentication fits an owner-operated deployment exactly and is deliberately not multi-tenant. Roles, delegation, and per-user scoping are unbuilt, and adding them will touch the enforcement layers.
- Model routing is modelled and validated in configuration but is not yet exercised by client code — the routing decisions are architected, not yet running.
- Provenance labelling costs a field, a check, and a constraint on every write path, and it makes some queries more verbose. It is the single most valuable property in the system.
- Keeping execution engines behind adapters means capability moves at the pace of the contract: a runtime feature is unavailable until it is expressed neutrally, which is slower than calling it directly.
11Outcome
The platform runs on a VPS under systemd with the control plane, the bridge, and the agent runtime as separate loopback-bound services, and a verified readiness handshake confirming the real executor is answering. The full vertical slice works end to end — register, dispatch, stream, approve, confirm, audit — with a documented rollback baseline and recovery evidence. What it is not: a multi-tenant product. It is a working, governed, single-operator control plane, and its own documentation is precise about which integrations are connected and which are not.
12Evidence
- Test and build verification
- 104 tests green, TypeScript compiling clean under --noEmit, production build green, and a 28-step scripted Playwright UI verification pass with desktop and mobile screenshots captured as artifacts.
- Deployment baseline
- A known-good baseline document records the verified commit, deployment identifier, service topology, expected health and authentication responses, the executor handshake, and the location of rollback evidence.
- Architecture decision records
- Eleven ADRs covering the adapter contract, Bridge Protocol v1, and the single-operator authentication design, alongside a data model, event schema, security model, and operations runbook.
- Agent roster
- The wider Hermes environment runs 10+ specialised profiles across engineering, operations, intelligence, creative work, revenue, and governance. The profiles named as integrated on this page are those in the bridge allowlist recorded in the verified deployment baseline, with roles quoted from the canonical agent profiles in source.
- Honest status reporting
- A per-integration connection-status document and a component table that explicitly mark what is implemented, configuration-only, or not implemented.