Write a short PRD: the input, the useful output, the receiver, boundaries, and what success looks like before you add a model.
FLAGSHIP BUILD REPORT + REFERENCE ARCHITECTURE
AGENTIC AI EMPLOYEES
The agentic fleet build guide
I built and operate an eight-employee AI fleet for Agentic Society. This public build guide shows the durable patterns behind it: cloud-first infrastructure, shared memory, model routing, caching, human review, and recovery when work does not go as planned.
Brain / body split
Scheduled + event autonomy
Self-healing
Single alerting layer
Code-to-production loop
Governed autonomy
Step 1. Agentic Fleet Build Guide
Start with the guide. Build with the prompt.
Read the first three pages for the path, then use the Session Zero handoff on page 4 to start building one useful AI employee. The remaining sessions cover cloud runtime, cron, durable state, observability, safe recovery, and the evidence needed to grow a reliable fleet.
Preview the build guide
Agentic Fleet Build Guide Preview
Review the 24-page guide, then download the complete build artifact for a founder, operator, or AI builder.
Page 1 of 24
Step 2. Agent Builder Starter Prompt
Start Session Zero with a guided interview.
Paste this copy-ready Markdown prompt into your build assistant. It asks ten plain-English questions one at a time, labels what you decided versus what it assumed, and then guides the build through the nine sessions in the guide.
Editable Markdown. Start here after pages 1 through 4 of the guide. You do not need to know the technical terms before you begin.
For first-time builders
If you are new to agents, start with one useful job.
Do not begin by inventing an entire org chart. Choose one repeated outcome, run it in the cloud, put a human approval moment around it, and make the result and failure visible. The fleet earns its next role through evidence.
Use a managed runtime, durable source record, and a narrow integration. A laptop can support development, but it cannot be the only place the agent runs or remembers.
Send an early result to Slack or email with clear approve, reject, or revise actions. Human correction is a product signal, not a hidden exception.
Give every run an ID, heartbeat, completion record, safe retry path, and one useful escalation when the system cannot finish correctly.
The build rule: no work is truly autonomous until it has a clear job, a visible human boundary, durable evidence, and a known recovery path.
The architecture
A small, inexpensive stack can run a real autonomous organization
The power is not in a giant platform. It comes from composing a few simple primitives into closed loops: behavior in plain language, a shared runtime, model-aware routing, durable state, ordinary APIs, and independent gates around production.
Behavioral brainSkills, memory, personalities, and operating rules in plain files.
Shared runtimeServerless functions, schedules, event triggers, auth, and one agent loop.
Control planeModel router, heartbeats, handoffs, cost ledger, reporting, and recovery.
Delivery bodyAPIs, GitHub, CI, pull requests, deployment verification, and rollback.
Discover, act, remember
Agents find work, load the right behavior, choose the right capability, act through tools, and leave a durable record.
trigger → skill → model → tools → memory
Improve, review, ship
The improvement engineer finds friction; the Director builds the fix; the independent Staff Engineer reviews it before production.
queue → branch → PR → review → deploy
Measure, report, recover
Heartbeats, cost snapshots, caching data, deployment checks, and recovery signals turn autonomous activity into accountable operations.
heartbeat → digest → alert → recover
The design principle: keep the infrastructure simple, then make the loops explicit. The result is an organization that can do more than a single chatbot without requiring a massive platform.
A working system
What this architecture makes possible
The point is not that eight agents exist. The point is that a small team of specialized agents can form a dependable operating system when the boundaries, loops, and evidence are designed together.
Schedules, event triggers, authentication, tool clients, and the agent loop live in one inexpensive serverless body.
Skills, memory, and personalities live in the cloud brain, so operating behavior can evolve like documentation.
The router sends routine work to fast models and reserves deeper reasoning for judgment and production gates.
Improvement becomes a queue-to-PR-to-merge loop with independent review, deployment checks, and rollback.
The roster
An autonomous organization, not a chatbot collection
Each employee has a lane, a memory, a manager, and a controlled path to action. The agents operate across working surfaces, the cloud brain, GitHub, CI, and the production runtime.
Operating employee
Agent | Project Manager
Project intelligence: action items, open loops, decisions, blockers, daily standups, and a structured tracker the whole team can read.
Operating employee
Agent | Chief of Staff
Knowledge work: turning meetings and signals into durable documents, profiles, briefs, and weekly digests that keep the organization aligned.
Control-plane employee
Agent | Director of Fleet Orchestration & Engineering
Runs and engineers the fleet: health, alerting, hand-offs, memory, cost discipline, change management, and the engineering queue.
Engineering employee
Agent | Continuous Improvement Engineer
Audits cost, caching, health, and recurring friction; ranks the engineering backlog and turns improvement opportunities into actionable work.
Independent merge gate
Agent | Staff Engineer
Runs autonomous code review against every eligible pull request, rejects unsafe changes, merges approved work, verifies production, and automatically reverts an unhealthy deployment.
Operating employee
Agent | RevOps Engineer
Turns revenue signals into clear operating intelligence, with a dedicated dashboard surface for pacing, scenarios, and decision support.
Operating employee
Agent | AI Correspondent
Runs the internal AI news desk, curating first-party changes and builder-relevant intelligence into timely editorial briefings.
Operating employee
Agent | Solution Architect
Drafts a grounded proposal before each Hot Seat, then learns from the room’s verdict through a reviewed improvement loop. The room is not tested by the AI. The AI is sharpened by the room.
How they relate
The specialist employees stay in their lanes. The Director is the operating manager and human-facing front door. The Continuous Improvement Engineer supplies the ranked engineering queue. The Staff Engineer stays independent of the code author, creating a second set of eyes before eligible work reaches production.
The organization
A company-shaped system with clear accountability
The org chart is not decoration. It defines who owns a lane, who coordinates the lanes, who reviews the code, and where human authority remains absolute.
H
Human OwnerFounder role · owner of direction, spend, and protected decisions
D
Director of Fleet Orchestration & EngineeringOperating manager · front door · fleet memory · change management
PMProject ManagerExecution intelligence
CoSChief of StaffKnowledge intelligence
RORevOps EngineerRevenue intelligence
CIContinuous Improvement EngineerBacklog intelligence
AIAI CorrespondentEditorial intelligence
SASolution ArchitectProposal intelligence
SE
Staff EngineerIndependent code review, merge, deployment verification, and rollback safety net
A human is always in charge
Autonomy with boundaries, not autonomy theater
The agents act independently inside explicit lanes. Human authority is concentrated where the downside is highest: protected code paths, credentials, spending, outbound commitments, and decisions that change the organization’s risk profile.
AutonomousRead, monitor, summarize, classify, coordinate, create issues, and maintain durable records.
Branch-onlyWrite code, open pull requests, and propose changes without writing directly to
main.Automated gateRun deterministic checks, adversarial review, eligible merges, deployment verification, and automatic rollback.
Human-controlledProtected paths, credentials, spend, outbound commitments, and high-risk changes remain the human owner’s call.
The core idea
The repo is the body. The cloud brain holds behavior.
A code repository holds the runtime: scheduling, authentication, the agent loop, integration clients, engineering workflows, and deployment safeguards. A cloud drive folder, the Company Brain, holds the behavior that can change safely as plain skill files.
Most jobs load their skill from the brain at runtime, so editing a skill changes behavior on the next run with no redeploy. The engineering agents are the deliberate exception: the Continuous Improvement Engineer and Staff Engineer live in the code-and-deployment loop because they must inspect, change, review, and verify the body itself.
The Body · code repo
Scheduling, auth, agent loops, integrations, engineering workflows, and production safeguards. Shipped by Git.
The Brain · cloud drive
Skill files, memory, and operating rules. Edited like documents; consumed at runtime.
Two update paths
Change behavior → edit a skill file in the brain. Live on the next run, no deploy. Change the system → open a branch and pull request; independent review, merge controls, deployment verification, and rollback protect production.
How it's wired
The stack, end to end
A multi-agent runtime across the cloud brain, working surfaces, GitHub, CI, deployment, and production systems. The architecture extends from human-facing work surfaces all the way to verified production.
The repo is the body (scheduling, auth, the agent loop in JavaScript). The cloud brain holds behavior. Each run loads its skill at run time, calls its clients, acts on the workspace and the shared tracker, pulls only the external data that job needs, and writes a heartbeat. That is the durable proof it ran.
Serverless runtime + cron
One Vercel project hosts every agent. The schedule is declared in vercel.json; each cron route maps one-to-one to a job. Crons run only on the production deployment.
The agent loop (JavaScript)
A shared handler injects a runtime preamble (identity, voice, rules), appends the skill from the brain, then runs a tool-use loop. The system prefix is cached so each round after the first is fast.
Model router
A shared routing layer chooses the right intelligence for each job: fast models for mechanical work, stronger reasoning for judgment-heavy operations, and the highest-review tier for the independent production merge gate.
Integration clients
Typed clients for the workspace, the structured tracker, the CRM, and the community. Each is called only by the jobs that need it, so no agent carries authority it doesn’t use.
Self-healing access
Data fetches try a cheap request first and fall back to an in-stack headless browser that clears bot challenges itself: no third party, no manual token grab. Tokens rotate from a brain file with an env-var fallback.
Intelligence routing
The fleet does not use one model for every job
The model router is part of the operating architecture. It matches model capability to task risk, keeps routine work economical, and reserves the strongest review for the decisions that can change production.
Mechanical tierFast modelHousekeeping, deterministic syncs, bounded data work, and repeatable reporting transforms.Typical jobs: health snapshots, data pulls, cache-safe updates.
Judgment tierReasoning modelStandups, scans, digests, orchestration, improvement planning, and human-facing work.Typical jobs: Chief of Staff digest, Director health pass, improvement plan.
Merge-gate tierStrongest independent reviewerAdversarial code review, protected production decisions, deployment verification, and rollback judgment.Typical jobs: Staff Engineer review, merge decision, production recovery.
Operating consequence: model choice becomes an operational policy, not a hidden implementation detail. The fleet spends reasoning where reasoning matters and keeps the cost, latency, and authority of each job visible.
The reliability loop
Autonomy becomes trustworthy when it can report and recover
The same simple runtime that runs the work also produces the evidence needed to govern it: heartbeats for execution, Anthropic cost snapshots for spend, cache savings for efficiency, and deployment checks for production health.
Collect evidenceHeartbeats, token usage, Anthropic cost snapshots, cache savings, and deployment status.
Synthesize healthThe Director compares activity against schedules, budgets, and expected production state.
Report clearlyA digest explains what ran, what it cost, what changed, and what needs attention.
Recover safelyFailures become routed work; unhealthy releases revert instead of becoming silent damage.
Key case-study insight: reporting is not a dashboard bolted on afterward. It is a control loop that closes the distance between autonomous action and accountable operations.
The self-engineering loop
From engineering queue to verified production
The fleet can improve its own runtime without giving one agent unchecked authority. Discovery, implementation, review, deployment, and recovery are separate responsibilities.
Find the workContinuous Improvement Engineer audits cost, health, caching, and recurring friction.
Build the changeDirector selects the top ticket, writes the fix on a branch, and opens a pull request.
Review independentlyStaff Engineer runs deterministic checks and adversarial code review.
Ship safelyEligible work merges, Vercel deploys, production is checked, and unhealthy releases revert.
What makes this autonomous: no single agent writes, approves, and ships its own change. The system separates initiative from authority and makes failure recoverable.
Inside a run
How one scheduled run executes
A shared handler turns a job name into identity, authority, a skill, and a record. The same seven stages run every time.
The schedule fires
A scheduled trigger calls the job at its configured time.
Authenticate
The handler rejects anything without the correct token, so jobs can’t be triggered by a random request.
Local-hour guard
The trigger fires on both standard- and daylight-time candidates; the job proceeds only at the correct local hour, so it lands on time year-round.
Load the skill from the brain
The handler maps the job to its skill file and reads that behavior live: the latest edit, every run.
Route the job and run the loop
The model router selects the job’s capability tier, then a runtime preamble sets identity, voice, and rules. The skill is appended and the shared prefix is cached, so each round after the first is fast and lightweight.
Act, then leave a heartbeat
The agent acts in the workspace, then writes a per-job heartbeat: durable proof it ran. On error it records the failure instead of paging anyone; the Director’s health pass is the single alerting layer, so a crashed job is never silent.
The operating layer
The Director is the operating layer over the fleet
The Director is both operator and engineering manager: it keeps the organization healthy, coordinated, accountable, and continuously improving across six functions.
Observability
A heartbeat ledger
Every job, on success or error, writes a tiny record: status, duration, summary, time. Best-effort, so it can never break a run. This is the durable record of whether the fleet actually ran.
Health & alerting
One synthesized digest
The Director reads the whole ledger against the expected schedule, with cold-start suppression and a grace window to avoid false alarms. For every problem it produces a root cause and a remedy, then alerts the owner only when something is actually actionable.
Work hand-off
The broker
Agents pass work to each other through a queue in the brain, with enqueue, list, and resolve operations exposed to the agent loop as tools. The Director drains and routes it. This is how peers coordinate without one bossing the other.
Front door & memory
Conversational, persistent
Through the workday the Director receives direction, routes work, enforces lane ownership, and keeps a living fleet-state memory current, so context survives across sessions.
Continuous improvement
A ranked engineering queue
The improvement engineer turns observed cost, caching, health, and workflow friction into ranked, measurable engineering work instead of vague ideas.
Change management
A controlled path to production
The Director works through branches and pull requests. Independent review, protected paths, deployment readiness checks, and rollback keep autonomy from becoming unchecked authority.
House rules
What stays intentionally simple
- Separate behavior from the body. Most agent behavior lives in the cloud brain; runtime code, engineering workflows, and deployment safeguards live in Git.
- All infrastructure in one project. Runtime, schedule, and every capability live together: not scattered across personal repos.
- Nothing on local disk. Artifacts the agents create go to the brain; temporary files are cleaned up.
- Skills belong in their agent’s folder. Each agent’s capabilities live under its own folder, never loose in the root.
- Autonomous, with explicit authority. Propose and act inside a lane; use independent gates for code; escalate protected paths and high-risk decisions.
- Voice is centralized per agent. Personality lives in one file per agent, so a voice change lands everywhere at once.
Stand it up
A minimal recipe for building one
The implementation is deliberately ordinary: one shared runtime, a cloud brain for behavior, a model router for capability and cost, and independent gates around production.
Give behavior a home
Keep skills, memory, personalities, and operating rules in plain files that the runtime can load and update safely.
Give the fleet one body
Put schedules, event triggers, authentication, tools, and the shared agent loop in one serverless runtime.
Make intelligence a policy
Route bounded work, judgment-heavy work, and production-gate work to different capability tiers so cost and authority stay visible.
Separate initiative from authority
Let agents find and build work on branches, then make independent review, deployment verification, and rollback part of the path to production.
Instrument the loop
Write heartbeats, cost snapshots, cache savings, and deployment status so the system can explain what happened and recover when it needs to.
Ship & roll back
One approved merge takes the body to production
Git is the source of truth for the body; Vercel is the only place it runs. A pull request passes through deterministic checks, independent review, merge controls, deployment verification, and rollback before it becomes a production change.
Push to main and the Vercel GitHub App builds and promotes to production, where the schedule runs. Any other branch builds a preview that never fires the schedule. Roll back in seconds by promoting a previous production build: no Git change required.
Push to main → production
The host auto-builds and promotes to production, where the schedule runs. No manual deploy, no CLI, no dashboard click.
Any other branch → preview
You get a testable preview with its own URL: but the schedule only fires in production, so a preview never acts on its own.
The schedule lives in config
Every job and its timing are declared in one file; each production deploy re-registers the schedule. Add or remove a job there and it takes effect on the next deploy.
Roll back instantly
Promote a previous production build to roll back in seconds: the escape hatch that doesn’t require a Git change.
If you’re building toward AI that does real work, not just answers, this build report offers a starting point: define the work, give it a brain, route intelligence by risk, and make every production change recoverable. If that’s the problem you’re sitting with, start a conversation.
Start the Conversation