Agentic frameworks for zero-human companies.
Most "agent" products today are coding assistants or customer-support chatbots — agents that sit on top of an existing org. The more interesting shape is the reverse: an org built on top of agents, where the operating layer is a fleet of always-on workers and the humans are a small board approving directions. This note describes our work on the substrate that makes that shape ship.
The problem
The first wave of agent products tried to put one autonomous worker into an existing seat — a single agent that drafts emails, or writes a PR, or schedules a meeting. The wins are real but the ceiling is low: the agent is gated by the surrounding org, which still operates on human time, with human handoffs, in human-shaped tools.
The interesting question is what happens when the org itself is restructured around always-on workers. Not "AI features in SaaS" — an entire operating layer where the agents are the staff. The systems of record exist for them, not for a human seat-holder. Every core function — go-to-market, ops, research, planning, communications — runs as recurring agent jobs, not as a person's weekly to-do.
Two things stop this from working today. First, the orchestration: there is no good substrate for many specialised agents to coordinate over the same shared state. Second, the trust budget: a single agent makes a bounded mistake; a fleet of agents acting in concert can compound errors quickly, so the audit and policy layer has to be in place before the speed-up shows up.
What we are building
A fleet harness. Specifically:
- A shared operational substrate. The agents work over the same systems of record a human team would — contacts, pipeline, work items, notes, messaging — not a parallel agent-only datastore. The agents are first-class users of the operational surface. This means anything a human operator does remains legible, and the company can still bring humans into the same surface without re-platforming.
- Specialised agents with bounded scope. Each agent has a job description, a tool list, and a single concern. The fleet is decomposed by function — one agent per core role — and wired together by an orchestrator, not by a single mega-prompt.
- A knowledge base as the agent's spec. Per-company documents — vision, ICP, voice, playbooks, KPIs — are the source of truth that drives the agents' behaviour. Onboarding the fleet is filling these in. The agents read them on every run. Updates to behaviour happen by editing the spec, not by re-prompting.
- Consensus rounds for strategic moves. For directional decisions — competitive responses, spend approvals, strategic pivots — agents vote asynchronously, the round is logged, and the human governance layer reviews the outcome. The fleet's reasoning becomes a readable artifact.
The output is an operating layer where the company runs while the founder is asleep, and the morning shows up as a brief: what the agents did, what they propose, what needs a signature. It is not "AI features bolted onto a workflow tool." It is the workflow.
Why this is a research direction, not a product
The naïve version of this — "string together a dozen agents and let them run a company" — works as a demo and fails as a deployment. The hard questions are not about chaining prompts. They are about:
- Coordination. What does it look like when twelve agents share state, and how do you keep them from contradicting one another in the same shift?
- Spec hygiene. How do you write a knowledge base that the agents actually read — not just a static document that drifts out of date the moment it ships?
- Bounded discretion. Which decisions live with the fleet, which decisions get held for a founder, and how does the answer evolve as confidence accrues?
- Drift detection. When the fleet's behaviour starts to drift away from the spec, how does that surface before the founder reads the morning brief and finds out the hard way?
These are the research questions we care about — closer to mechanism design than to ML engineering. The interesting frontier isn't "can the agent draft a better email?" It's "what is the shape of an organization where the operating layer is software and the human layer is governance?"
Applied with the ecosystem
Crypto-native businesses are the natural first ICP for this work: signal is structured and on-chain, settlement happens in seconds, and the operating tempo already matches what an always-on fleet can deliver. The first deployments run inside companies that share infrastructure with the Aventus ecosystem — treasury, settlement, identity — which means the fleet is wired to the same rails the rest of the lab's work runs on.
The crypto-first lens generalises. The same fleet pattern works for any company whose data is structured and whose action surface is programmable. As soon as the substrate of the work the company does becomes legible to software, the question of whether software can do the work in the first place stops being a thought experiment.
The open questions are around spec hygiene, coordination, and drift. The deployments are small. We expect to be wrong about half of what we currently believe, and the half we are right about is the half worth writing down.