AI Infrastructure for Startups: What to Set Up Early

A startup should set up five things early for AI: accounts owned by the company, memory kept in readable files, permissions that start narrow, logs of what the agent did, and a named human owner. These foundations are cheap while the team is small and expensive to retrofit once habits, data and credentials have spread. Model choice, tooling and polish can change later if these five hold.

Key takeaways

• Put every AI account, key and integration under the company, never under one person's login.
• Keep the agent's memory in files a person can read, correct and export, so it survives staff changes and provider changes.
• Give each agent the smallest set of permissions its role needs, and widen them only after review.
• Record what the agent saw, decided and did, so you can answer "what happened?" without guessing.
• Name one owner per agent. Most of the rework in young companies comes from agents nobody is responsible for.

Why do startups need AI infrastructure before they need more AI?

Small teams move by improvisation, and that is usually a strength. Someone signs up for a tool with a personal email, pastes a few documents into it, connects it to the shared inbox, and the team gets a useful result by the end of the day. The problem appears later, when the same improvisation has been repeated a dozen times and nobody can say which tool holds which data, who can change what, or why an answer changed last Tuesday.

Infrastructure here does not mean servers or a platform team. It means the boring decisions that make an AI agent a reliable part of the company instead of a personal experiment: whose account it runs on, where its knowledge lives, what it is allowed to touch, and how you find out what it did. If you want the full picture of every layer, The Seven Layers of Company AI Infrastructure, Explained maps them. For a startup, four of those layers deserve attention on day one, and the rest can wait.

A useful test is the departure test. Imagine the person who set up your first agent leaves tomorrow. If the team can still log in, read what the agent knows, see what it did last week and change its behavior, your foundations are in place. If any of those fails, you have a dependency on one person.

Which accounts should the company own from day one?

The first foundation is ownership. Every account connected to an AI agent should belong to the company: the model provider account, the workspace where the agent runs, the email or chat identity it uses, and the billing relationship behind them.

Three habits prevent most of the trouble:

• Create a shared administrative mailbox for the company (for example, an address that forwards to two founders) and register AI tools with it, not with a personal address.
• Give the agent its own identity in each system it touches, such as its own mailbox or its own service user, so its actions are never mixed up with a human's.
• Store credentials in a password manager or secrets store with at least two administrators, and never in a chat message, a shared document or a prompt.

The agent's own identity matters more than it seems. When an agent acts through a founder's personal login, every action looks like the founder's action. You lose the ability to tell human work from agent work, and you cannot remove the agent's access without removing the founder's. A separate identity can be paused, limited or deleted on its own.

Where an agent connects to Google or another provider on a person's behalf, understand how delegated access works. The [OAuth 2.0 overview from Google](https://developers.google.com/identity/protocols/oauth2) explains how applications request limited access to user data, which is the model you want: scoped access that can be revoked, rather than a shared password.

What should the agent remember, and where should that memory live?

The second foundation is memory. An agent is only as useful as the context it carries: who your customers are, how you price exceptions, what tone you use, which topics need a human. Startups tend to let that context accumulate invisibly inside a chat history or a vendor's proprietary memory feature. It works until you want to correct it, audit it or move it.

A better default is to keep durable memory as plain documents that a person can open. Separate three kinds:

• Standing instructions: the role, the tone, the rules, the escalation conditions. These change rarely and should be versioned.
• Reference knowledge: product details, policies, process descriptions. These change with the business and need a named person who keeps them current.
• Working notes: what the agent learned during recent tasks. These are the riskiest, because errors in them quietly compound, so review them on a schedule.

This separation follows the logic described in Anthropic's piece on [effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents): what an agent sees at each step is a limited resource, and curating it deliberately beats dumping everything in. For a startup, the practical consequence is simple. Smaller, cleaner, owned documents produce better behavior and are far easier to move to another provider. That portability is the heart of avoiding AI vendor lock-in, and it costs almost nothing if you decide it at the start.

Two cautions. First, do not put into memory what the agent does not need. Personal data, credentials and confidential negotiations rarely belong there. Second, decide who may edit memory. If anyone can change the standing instructions, the agent's behavior will drift, and nobody will know why.

How narrow should permissions be at the start?

The third foundation is permissions. The instinct in a fast team is to connect everything so the agent can "just handle it." The safer instinct is to start with read access to the minimum set of sources, add write actions one at a time, and keep a human approval step in front of anything that cannot be undone, such as sending to a customer, changing a record, or moving money.

This is the principle of least privilege, and the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) states it plainly: grant only the access a function needs, and enforce checks on every request rather than assuming trust. It applies to agents as much as to people, perhaps more, because an agent can act quickly and repeatedly on a mistaken instruction.

A simple decision guide for each action an agent might take:

• Can it be undone easily and cheaply? Let the agent do it and log it.
• Can it be undone, but with effort or embarrassment? Let the agent prepare it and require a human click to send.
• Can it not be undone, or does it involve money, legal commitments or sensitive personal data? Keep it human, or require explicit approval each time.

Write this down per agent, in one page. When the team later asks "can the agent do X?", the answer should come from the page, not from someone's memory. That page is also the starting point for the first permission review, which you should schedule before you need it. Do not forget the other direction: when permissions are reduced, the team should know, so nobody is surprised that a task now needs approval.

If the agent reads outside content such as emails, web pages or uploaded files, treat that content as untrusted input. Text inside a document can try to redirect an agent, which is why narrow permissions are your last line of defense. The [OWASP guidance on prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) is a good short read for whoever owns this.

What should you log so you can explain what the agent did?

The fourth foundation is a record. When something goes wrong, or when something goes surprisingly well, you want to reconstruct what happened: what the agent was asked, what information it used, which tools it called, what it produced, and who approved it. Without that, every incident becomes an argument about memory.

Start with a modest log, not a monitoring platform. For each task, keep:

• The request and who or what triggered it.
• The sources and memory the agent used.
• The actions it took and the results of those actions.
• Any human approval, with the name and the time.
• The cost of the task, if your provider reports it.

The general idea comes from observability: a system is understandable when it emits enough signals to answer questions you did not anticipate. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) describes logs, metrics and traces in plain terms, and you can adopt the vocabulary without adopting the tooling yet. If your agent will eventually serve customers or touch regulated data, see how stricter record-keeping works in AI agent audit trail requirements, and plan a log format that can grow into it.

Two practical points. Decide how long logs are kept and who can read them, since logs often contain the same sensitive data you were careful about elsewhere. And review a small sample regularly. A log nobody reads is storage, not control.

Illustrative scenario: the founder's inbox agent

This is an illustrative scenario, not a real case. A five-person company sets up an agent to draft replies to inbound customer questions. In the quick version, a founder signs up with a personal email, connects her own inbox, pastes in the product documentation, and lets the agent send replies directly.

It works for a while. Then the founder takes a holiday and a teammate needs to change how refunds are described. Nobody can find where the instructions live. The agent is sending from the founder's address, so replies look personal. A customer disputes something the agent said, and there is no record of which document it relied on.

In the foundations-first version, the agent has its own mailbox under a company domain, registered through the shared administrative address. Its instructions and product notes sit in three documents with named owners. It can read the support inbox and draft replies, but a human approves each send until the team trusts the pattern. Each task leaves a short log entry. The refund wording change takes a few minutes, the holiday is uneventful, and the disputed reply can be traced to its source. The difference was a handful of decisions made on the first day, not extra technology.

What is a sensible order for setting this up?

You do not need a project to do this. A founder or operations lead can work through the following in a few focused sessions, before the second agent arrives.

• Name an owner for each agent, and a backup owner. Write both names in the instructions document.
• Create or confirm the company-owned administrative account, and move any personally registered AI tools under it.
• Give the agent its own identity in each connected system, and remove personal credentials from any setup.
• Write the one-page role description: what the agent does, what it never does, and when it hands over to a person.
• Move durable knowledge into readable documents, and assign someone to keep each current.
• List every permission the agent holds. Remove what the role does not need, and mark which actions require human approval.
• Turn on logging for tasks, tool calls and approvals, and set a retention period.
• Set a usage limit and a budget alert with your provider, using the approach in AI agent usage limits and budget alerts.
• Put a recurring date in the calendar for a permission and memory review.

What can wait: choosing between many models, building a custom evaluation harness, elaborate dashboards, and a formal governance program. Draw a rough picture of how the pieces connect, even a hand sketch, using something like the one-page architecture map. Revisit the rest when the number of agents or the sensitivity of the data grows.

How does Be Human handle these foundations?

Be Human designs, implements and operates personalized AI infrastructure for companies, and these foundations are where a first engagement begins. We define one useful role for the agent, then set up the identity, memory, channels, tools and permissions it needs, with approval boundaries agreed with you and an observable success criterion. Accounts and memory stay under your control, and day-to-day operations such as monitoring, recurring evaluations, integration maintenance and permission review can be run for you. The service is remote, in English and Portuguese.

Frequently asked questions

Do we need a dedicated person for AI infrastructure at this stage? No. In a small team, the owner role is a responsibility, not a job title, and it usually sits with a founder or an operations lead. What matters is that the name is written down, and that the person has time for a short review on a regular schedule.

Should we pick one AI provider or keep our options open? Choose one to start, but keep your instructions, knowledge and logs in formats you control, so that switching is a matter of reconnecting, not rebuilding. Options stay open through portable memory and company-owned accounts, not through running several providers at once.

When is it worth moving from a quick experiment to this kind of setup? Move as soon as the agent touches real customer data, sends anything outside the company, or more than one person depends on it. Before that, an experiment can stay informal, but note what you would change before relying on it.

How much of this applies if our agent only drafts internal documents? The ownership, memory and ownership-by-name points still apply in full. Permissions and approval steps can be lighter because mistakes are contained, but keep a simple log, since internal drafts often feed later decisions and you will want to know where they came from.

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