Superintelligence for a Two-Person Company: The Minimum Viable Layer

The minimum viable superintelligence layer for a two-person company is one AI agent with a single defined job, a written memory file that holds the context it needs, a short list of tools it may use, and a weekly review where the owners decide what changes. Nothing else is required to start. The layer works because it stays small enough to inspect, bounded by approval rules, and improved on a fixed rhythm instead of by ad hoc additions.

Key takeaways

• One agent with one job is easier to trust, test and correct than a general assistant connected to everything.
• The memory file is a maintained company record with owners and review dates, not a pile of chat history.
• Keep the tool list to the actions the role truly needs, and mark every write action that requires human approval.
• The weekly review of corrections, escalations and new context is what makes the layer improve over time.
• Define one success criterion before the first week, or no one can say whether the layer is worth keeping.

Why a two-person company needs a layer at all

Two people in a small company usually carry the customer history, the supplier follow-ups, the quoting rules and the handoffs between them in their heads. When one of them is busy or away, that knowledge stops moving. An AI layer does not fix this by being clever. It fixes it by moving recurring knowledge and recurring work into a form that can be read, corrected and handed over.

Many leaders start with the opposite approach: a broad assistant connected to the inbox, the shared drive, the calendar and the accounts, with the hope that it will figure out the business. That creates three problems at once. Nobody can say what the assistant is for, nobody can see what it changed, and nobody can judge whether it worked. The minimum layer avoids all three by being narrow on purpose.

If you want to see where each component sits before you draw your own, the one-page map in Draw Your AI Stack: A One-Page Architecture Map for Leaders gives a useful reference.

The four parts of the minimum layer

The layer has four parts, and each one has a single purpose.

• One agent with one role, such as answering inbound questions about a fixed catalogue or drafting weekly payment reminders for a person to approve.
• One memory file that states who the customers are, what the company offers, what it never promises, and who decides what.
• One short tool list with no more than the few actions the role needs, each with a clear read or write scope.
• One weekly review, kept to about thirty minutes, where the two owners read what the agent did and decide what changes next.

Notice what is absent. There is no orchestration of several agents, no custom model training and no dashboard. Each of those can become useful later, but a two-person company that adds them first usually spends its attention on the machinery and learns little about the work. The four parts above are enough to produce evidence.

Writing a memory file the agent can actually use

A memory file is working context, not a transcript. Its job is to give the agent the smallest set of information that lets it act correctly, and to keep that set current. Anthropic's engineering guidance on context engineering makes the same point: good context is high-signal and deliberately limited, not an archive of everything ever said.

A useful memory file for a small company usually holds five sections:

• Role: what the agent does, what it does not do, and who it reports to.
• Customers: the common request types, the language customers use, and the exceptions that need a human.
• Offer: the products or services as the owners currently state them, with the wording that must never be promised.
• Boundaries: the actions that require approval, and the topics that go straight to a person.
• Ownership: the name of the owner for each section and the date it was last reviewed.

The last section matters most. Stale memory is worse than no memory, because the agent will be confidently wrong using old terms. Each section should have one owner and a review date, and any change should be recorded in the weekly review rather than made silently in the chat.

Keeping the tool list short and the permissions honest

Every tool is a capability with a blast radius. Before connecting anything, ask what the worst plausible action would be if the agent misread a message or followed an instruction it should not have followed. Content the agent reads, such as inbound emails or uploaded documents, can contain text that tries to redirect it, so the safest default is read access plus human approval for anything that leaves the company.

The OWASP authorization guidance is built on deny-by-default and least privilege, and those two ideas are enough for a two-person company to start. Grant the narrowest scope each provider offers, and prefer a separate account or calendar for the agent over sharing a personal login. Write each tool down with four fields:

• What it reads.
• What it writes, if anything.
• Which actions need a human to approve first.
• What the agent must never do with it.

A list of four tools with these fields usually fits on a single page. If it does not, the role is probably too broad. For a fuller procedure you can reuse each quarter, see How to Run a Permission Review for Your AI Agents, Step by Step.

The weekly review that makes the layer compound

Compounding comes from the review, not from the model. Without a review, the agent's mistakes are fixed by whoever notices them first, in whatever way is fastest that day, and the lessons disappear. With a fixed review, each mistake becomes a dated change to the memory file, the tool list or the approval rules.

The records needed for this review are simple: a log of each action with its time, the input, the output and whether a person approved it. OpenTelemetry's observability primer describes this kind of telemetry, covering traces, metrics and logs, as the basis for understanding how a system behaves from the outputs it produces. A two-person company does not need the full stack. A plain, consistent log is enough to answer the review questions:

• Which requests did the agent handle without correction?
• Where did a person step in, and what was the reason?
• Which memory entry was wrong, missing or out of date?
• Did any tool call reach further than the role needs?
• Did the success criterion move in the expected direction?

Illustrative scenario: imagine a two-person studio that sells workshop bookings. Its agent answers booking questions from the memory file and drafts replies for an owner to send. In the third weekly review, the log shows it quoted an old cancellation window. The fix is one changed line in the memory file, a new review date on that section, and the approval step stays in place until the next review confirms the correction.

A four-week plan to start

The following sequence keeps the first attempt small and measurable.

• Week one: write the role in one sentence and the success criterion in one sentence. Choose the single task that repeats most often and has the least irreversible consequence if handled badly.
• Week two: draft the memory file, have each owner correct it separately, then merge the differences and record the decisions.
• Week three: connect the narrowest tools, keep every write action behind approval, and switch on the action log.
• Week four: run the first weekly review, record what changed, and decide whether to widen the scope, hold it steady or stop.

A decision to stop in week four is a legitimate result. If the task turns out to be the wrong one, the memory file, the log and the permission notes still have value for the next attempt. The practical steps for closing a trial without losing that work are described in How to Stop an AI Pilot Without Wasting the Work Already Done.

How Be Human runs this layer for a company

Be Human designs, implements and operates personalized AI infrastructure for companies, including agents that keep their identity, memory, channels, tools, permissions and operating context under human control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the owners spend their weekly time on decisions rather than on plumbing. The work is remote and available in English and Portuguese.

If you are unsure which task should go first, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Is one agent enough for a two-person company? Usually yes, at the start. One agent with a single role gives you a clear owner, a contained set of tools and a log you can read in a few minutes. Additional agents can be added later, when the evidence shows that a second role is needed and that the first one is reliable.

How long should the memory file be? Short enough that both owners can read it in one sitting and correct it without a meeting. Every line should change the agent's behaviour or prevent a specific error, and anything else belongs in a reference document the agent does not load by default. Review the whole file at each weekly review so it does not drift.

Should the agent be allowed to send messages on its own? Start without that permission. Let it draft, and have a person approve each outgoing message until the log shows a stable pattern for that specific type of request. Widening autonomy should be a recorded decision in the review, not a default that appears after a setting is changed.

How will we know the layer is working? Check the single success criterion you wrote in week one against the log at each weekly review. If corrections fall, escalations are the right ones, and the owners spend less time on the task, the layer is earning its place. If nothing moves after several reviews, change the task or stop, and keep the artifacts for the next attempt.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.