Since March 2026, Ampron's sales, operations, finance, production and marketing have been handled by AI agents. Each has a defined role, its own identity, its own tools and written limits. Four people keep every decision that carries real consequences. This memo describes how the system is built, how we operate with it day to day, and what we would tell anyone building the same thing.

01What runs today

10 agent seats	A Chief of Staff, five domain directors, a technical assistant, a research scout, a monitoring observer and a platform engineer.
4 people	The owner as decision layer, the chief engineer, and two people in production and warehouse.
7 months	In production since March 2026. One platform rebuild in July replaced thirty hand-copied services.
1 server	Self-hosted Linux in the EU. No GPU. Reasoning runs on Anthropic Claude models through an API; the server only orchestrates.

The slide version of this memo: Note №15.

02Five layers

Humans on top, tools at the bottom, and everything in between written down.

Layer	What it holds
Humans	The owner approves, accepts finished work and answers structured questions. Only people move money, sign legal documents, hire, set pricing floors or change ownership.
Governance	A company constitution with values and hard limits, a decision register with evidence, a source-of-truth registry that says which system wins when data disagrees, and send policies per agent.
Agents	Each agent is one configuration file: role, model, tools, mailbox, limits. Everything else is generated from it.
Coordination	Dispatch (logged, threaded memos), the Issue Board (finished work goes to Review for human acceptance), Intake (structured questions when a person must decide), Calendar (deadlines that wake agents), and portal chat.
Tools and data	Agents reach business systems only through MCP connectors, scoped per agent: ERP (Odoo), documents and knowledge base (Nextcloud), email, production boards (Trello), around 13,000 company documents, a ten-year email archive, the bank (read-only) and factory cameras.

Agents never touch business systems directly. Everything passes through a tool gateway, and policy is enforced there, in code.

03How an agent runs

An agent is a configuration, not a long-running program. The platform turns each agent into short, bounded runs: the model receives that agent's instructions and tools, does the work, writes down what it did, and exits. Nothing thinks between runs. All state lives in systems the company owns.

Limits on every run

• Wake. A memo, an assigned task, an answered question, a chat message, or the schedule. Scheduled checks run every two hours on working days; there are no runs at weekends.
• Time limit. 20 to 30 minutes per run, with up to two automatic continuation rounds for long jobs.
• Daily token budget. Per agent. Over budget, the agent pauses until the next day and says so once. A cap on wakes stops two agents replying to each other forever.
• One run at a time. A lock prevents a scheduled round and an event wake from colliding. Long conversations are compacted before they grow too large to handle reliably.

One file per agent

Every agent is defined by one short manifest. A generator turns it into everything else, and nobody hand-edits a generated file.

From this file the generator produces the tool configuration, the service units and schedule, the web routes and identities, and the agent's full system prompt. Five deploy gates run before anything goes live: schema, live endpoint probes, auth preflight, room checks and prompt coherence. A deploy that cannot verify itself fails loudly.

04The team

Seat	Responsibility
Chief of Staff	Coordinates the team, tracks goals, runs the cadence, turns problems into decisions for the owner. Owns no domain itself.
Sales	Leads, quotes within pricing floors, customer correspondence, CRM. Drafts; outreach ships on human approval.
Finance	Invoices, payment follow-up, reconciliation against read-only bank data.
Operations	Orders, logistics, suppliers, delivery tracking.
Production	Manufacturing plan, work orders, shop-floor status on the production boards.
Marketing	Website, content, social drafts. No write access to other domains.
Technical	Product knowledge, documentation, troubleshooting. Read-only ERP.
Research scout	Market and partner research outside the company. Writes findings to the knowledge base.
Monitoring	Watches systems, outcomes and the fleet's own health. Read-only by construction.
Platform Engineer	Builds, fixes and secures the platform itself. The only agent with elevated access, through a guarded, logged wrapper.

The rule that holds it together: domains own domains. No agent reaches into another agent's tools.

05Charters and memory

Every agent has a written charter: its domain, its authority and limits, its voice, and when to escalate. Edit the charter, redeploy, and behaviour changes within fifteen minutes. The agent's prompt is assembled from four parts. Two are written by people (shared blocks inherited by every agent, and the role charter) and two are generated from the manifest (the tools section and the policy section). The human-readable rules and the machine-enforced rules come from the same source.

Memory lives in company systems, not in the model.

• Diaries. Each agent appends a short entry after every run, and the recent tail is fed into its next run. Older entries are condensed monthly.
• Knowledge base. People, companies, products and processes, plus around 13,000 historical documents and ten years of email. Agents read it before asking a person, and write back what they learn in the same run.
• Systems of record win. The ERP, the mailbox, the issue board and live service status are the truth. Any claim such as "sent", "paid" or "deployed" is re-checked against the owning system before it is repeated.

Retire an agent or change the model, and the memory stays.

06The operating loop and the three gates

Every run follows the same five steps.

1. Wake. A message, a task, an answered question, or the two-hourly schedule.
2. Check the record. The agent reads the actual systems (ERP, mail, board, calendar), not its own memory. Memory says where to look; the system says what is true.
3. Act within its role and permissions. Nothing outside its tool list is possible.
4. Hand off or escalate. Agents work with each other through Dispatch. They reach a person only through one of three gates.
5. Log. Diary entry, memo thread, audit trail. Then exit.

The three gates are the only ways work reaches a person:

• Review: "I finished this, please accept." An agent cannot mark its own work done; a person closes the card.
• Intake: "I need a decision only you can make." A structured questionnaire, answered at the person's pace. No agent blocks waiting.
• Blocked: "I can't proceed, and here is exactly why." The one state allowed to be loud in the interface.

07An example: a quote request

1. The Chief of Staff spots the customer's email in triage, recognises it as commercial, and routes a memo to Sales.
2. Sales pulls the customer's history from the CRM and the ten-year archive, checks the pricelist in Notes, and drafts the quote in the ERP.
3. The owner gets a one-line "Send?" in chat and approves. The mail connector releases the draft only if it is unchanged since the approval.
4. Sales sends, logs a memo, and updates the lead: stage, expected revenue, next activity.
5. Monitoring sees the send in the audit trail. If the customer is silent for fourteen days, the lead surfaces again on the board.

Human input: one approval. Replace "quote" with "supplier delay" or "overdue invoice" and the shape is identical; only the agent changes.

08The cadence

When	What happens
Every 2 h	Every agent drains its queues on working days: memos, cards, answered questionnaires, calendar items. A round that finds nothing posts nothing.
08:00	The Chief of Staff writes the morning brief: what needs the owner, which agents are waiting, fleet health, and the overnight agent-to-agent activity.
During the day	The owner works the three gates: accept, decide, unblock.
Monday	Every agent writes its top frictions and proposed fixes. The Chief of Staff reads the set, finds patterns, and brings them to the weekly meeting with the owner.
After any mistake	A root-cause analysis (5 Whys). The fix is written back as a rule the platform enforces or a check the deploy gates run.

09Rules in code, not in the prompt

A rule that exists only in the prompt is a suggestion; the model can reason its way around it. Everything that matters is enforced in the tool servers.

Send policy, set per mailbox

Level	Meaning
0 · None	The agent sends nothing.
1 · Draft-only	The agent drafts, a person sends.
2 · Supervised	A person approves in chat. The connector releases the draft only if it has not changed since the approval.
3 · Autonomous	Only for low-risk operational mail, and only once earned.

• Verified internal senders. Internal mail is accepted only after three checks: sender on an allowlist, DKIM signature matching the domain, and arrival through the company's own mail provider. Reply recipients are computed from the original message, never chosen by the agent.
• No new destinations for data. Outgoing drafts are scanned for commercial terms, credentials and personal data. Data goes only to contacts already on record. Requests to change bank details or addresses always go to a person.
• Human-only gates. No agent can spend money, sign anything legal, hire anyone or change pricing floors. An agent with no payment tool cannot make a payment.

10Security and control

• Separate identity per agent. Own mailbox, document account, ERP connector and board identity. Every action is attributable to the agent that took it.
• Least privilege. Tools are scoped per role. Technical has a read-only ERP connector; Sales has no bank access; Monitoring has no write tools at all.
• External content is data, never instructions. Emails, attachments and web pages cannot command an agent. Prompt injection, invoice-fraud patterns and lookalike domains are flagged to a person.
• Guarded admin access. Privileged operations pass through a wrapper that logs every call and blocks mass deletion, disk wipes, dropping databases and edits to its own permissions.
• Spending limits. A daily usage cap per agent, and the platform's token use accounted for.
• Full audit trail. Memos, decisions, task history and admin actions are recorded and searchable. Agent memos are signed.

If an agent is manipulated

We assume some attacks will succeed, and limit what a compromised agent can do. It cannot send to anyone the tool layer does not allow. It does not choose reply recipients. It cannot reach systems outside its scope. Irreversible operations are blocked even with elevated access. Every action is attributed and logged, so a deviation can be traced afterwards. Every incident becomes a rule.

11The portal

Agents and people work in the same eight apps, on the same record. Every message, memo, card and document shows who made it, human or agent, verified. Red is used only for what needs a person.

Screenshots are from the live suite in July 2026; some data is demo data.

12Nine mistakes we made

Mistake	What happened	Fix
Silent failure	Scheduled jobs died for days and nobody noticed.	Liveness checks that test the real outcome, not the timer; a monitoring agent and a daily smoke test of every tool connection.
Policy only in the prompt	The model sometimes reasoned around it.	Every rule that matters moved into the tool server.
Promises that evaporated	"I’ll get back to you" was lost on restart.	A pending-task ledger, calendar wakes, and a rule: a promised deliverable gets a tracked card in the same run.
"Committed" is not "deployed"	A change was saved but never went live.	Nothing is done until it is verified on the running system.
Memory treated as truth	An agent repeated an outdated claim from its notes.	Diaries are advisory; every claim is re-checked against the system of record.
Configuration drift	About thirty hand-copied services drifted apart.	One platform, one manifest per agent, everything generated, five deploy gates.
Agents echoing each other	Agents replied to each other in shared rooms.	Mention-only rooms, wake caps, and a structured memo bus instead of chat.
One shared quota	One quota for the whole fleet: everyone went dark at once.	Per-agent budgets, quota monitoring and staggered schedules.
Test copy touched live data	A staging copy pointed at the production database through an absolute path.	Staging must point every data path at a scratch copy, or it does not start.

Each of these is now a written rule in a lessons ledger the platform must honour.

13Building your own

What you need to start

• One server or VM, an LLM API account, and an MCP-capable agent runtime.
• Three or four connectors to systems you already have: mail, documents, a task system, and one business system, read-only to start.
• One shared constitution, one charter per agent, and a written list of what only people may do.
• A memo channel and a decision channel between agents and people. A shared chat room is not enough.
• A diary per agent and a written knowledge base.
• Two or three agents: a coordinator, one domain agent, and a monitoring agent that can only read.

What to build first, in order

1. The constitution and the human-only list: spend, sign, hire, publish externally without review.
2. A read-only agent. Monitoring or research cannot break anything, and it shows you the failure modes cheaply.
3. The escalation channels (review, decision, blocked) before any write access.
4. Draft-only write access: the agent prepares, a person sends.
5. Supervised, then autonomous sending, per mailbox, only once it has earned trust.
6. Agent-to-agent coordination, only once each agent is reliable on its own.

Roughly what it takes

Estimates from our own build, not measurements. Most of the time goes into governance, hardening against failure and connecting existing systems, not into AI.

Pilot	4 to 6 weeks: two or three read-mostly agents, one engineer who knows your systems, plus time from whoever writes the charters.
Production team	4 to 6 months: eight to ten agents with write access, through repeated iteration.
Running cost	A modest server plus model usage. Usage dominates; per-agent budgets keep it bounded.
Ongoing	One role owns the platform. At Ampron that role is itself an agent, supervised by the owner.