AI Assistant Setup for a Solo Consultant: A Lean First Build

A good AI assistant setup for a solo consultant starts with one defined role, not a tool. Pick one recurring job, give the assistant a short written memory of how you work, connect only the two or three tools that job needs, and decide in advance which actions require your approval. Keep the whole arrangement small enough that you can explain it in a paragraph and review it in one short sitting each month.

Key takeaways

• Start with one role and one observable success test, such as drafting first-pass follow-up notes you edit in a few minutes.
• Keep memory small, written in plain files you can read, and separate your working notes from client confidential material.
• Give every tool the narrowest access that lets the job work, and prefer read access over write access until trust is earned.
• Decide which actions the assistant may take alone, which need your approval, and which it must never take.
• Review the setup on a calendar, because a one-person practice has no colleague who will notice when something drifts.

Why does a one-person practice still need infrastructure?

When you work alone, you are the operations team, the security team and the only person who knows what the assistant is allowed to do. That is an advantage, because there is no committee. It is also a risk, because nobody else will notice if the assistant starts sending drafts from the wrong account, quoting an outdated service description, or holding on to a client file long after the engagement ended.

Infrastructure here does not mean servers. It means a few decisions made on purpose and written down. The same layers that larger companies manage (identity, memory, channels, tools, permissions and operating context) exist in a solo practice too. They are just small. If you want the full picture of how these layers fit together at company scale, The Seven Layers of Company AI Infrastructure, Explained is a useful reference to keep nearby while you scale them down.

The practical test is simple. If you were unavailable for two weeks, could someone you trust open a single document and understand what your assistant does, what it can touch and how to switch it off? If not, the setup is not finished, however well the assistant writes.

Step one: choose one role and one success test

The most common mistake in a first setup is asking the assistant to help with everything. A broad request produces a broad, unreviewable system. A single role produces something you can judge.

Good first roles for a consultant tend to be repetitive, text-heavy and low in consequence if a draft is imperfect:

• Turning meeting notes into a structured summary and a list of follow-ups.
• Drafting the first version of a proposal from your own past proposals.
• Preparing a pre-call brief from the notes you already hold on a client.
• Sorting inbound inquiries and drafting a reply for you to approve.

Pick one. Then write the success test in a sentence you could check without a spreadsheet. For example: after a call, I receive a summary within a few minutes that I can send with only light edits, and it never invents a commitment I did not make. That sentence tells you what to watch for. It also tells you when to stop and fix something rather than keep going.

This is the same discipline larger organizations apply when they define a pilot. If you want to go deeper on writing a good test, How to Define Success Criteria for an AI Agent Pilot covers it in more detail.

Another point worth settling now: the assistant is a role, not a person. Give it a name and a one-paragraph job description. Write what it is responsible for, what it is not responsible for, and who it answers to (you). A short description keeps later additions honest, because each new request can be checked against it.

Step two: build a small memory you can actually read

Memory is where a solo setup can quietly go wrong, so keep it plain. The goal is not to give the assistant everything you know. The goal is to give it the minimum context that makes its output sound like your practice and be correct about your facts.

A lean memory has three parts, each kept as a readable document:

• A practice profile: who you serve, what you offer, how you describe your services, your tone, words you avoid and your standard terms of engagement.
• A style and examples file: a handful of your own past documents that you consider good, with a note on why each one works.
• Client notes: one short page per active client with preferences, history that matters and anything the assistant must not mention.

Resist the urge to dump your whole archive into the assistant. Retrieval from a large pile of unsorted documents tends to surface old, contradictory or irrelevant material, and you will not know why a draft said what it said. Smaller, curated, dated notes are easier to trust. Anthropic's guidance on [effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) makes the same point from the engineering side: what you place in front of the model matters more than how much you place there.

Two habits keep memory healthy. First, date every note and name the source, so you can tell a current preference from a stale one. Second, separate client confidential material from your general working notes, and close the client section when an engagement ends. If a client contract restricts where their information may be processed, that restriction belongs in the client note itself, where both you and the assistant will see it.

Back up the memory documents too. They are the part of the setup that took your judgment to create and the part you cannot easily recreate. AI Agent Backup and Restore: What to Save and How to Test It explains what is worth saving and how to confirm a restore works before you need one.

Step three: connect few tools, with the narrowest access that works

Every connection you add is a door. A solo consultant usually needs fewer than expected: email or messaging, a calendar, a document store and perhaps a notes app or invoicing tool. Add them one at a time, and only when the chosen role requires them.

For each tool, answer four questions before connecting it:

• What exactly does the role need from this tool? Name the task, not the product.
• Can it work with read access alone? If so, stop there for now.
• Which account or folder does it need? Limit it to that account or folder rather than the whole workspace.
• How will I revoke it? Know where the access is granted and where you remove it.

When a tool connects through a sign-in flow, look at the scopes you are being asked to approve. The standard behind many of these flows is [OAuth 2.0 authorization](https://developers.google.com/identity/protocols/oauth2), which exists precisely so an application can receive limited access without holding your password. Treat a request for broad scopes as a prompt to ask whether a narrower option exists. The general principle, that each actor should hold only the permissions its task needs and that checks should happen on every request, is laid out in the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).

Give the assistant its own identity where you can: its own email alias, its own login, its own folder. That way its actions are visible in logs as the assistant's actions, and removing its access does not disturb your own accounts.

One risk deserves attention in a consultant's setup in particular. If the assistant reads incoming email or documents from outside parties, those texts can contain instructions aimed at the assistant rather than at you. The [OWASP prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes why external content should be treated as untrusted. The practical consequence is this: an assistant that reads outside material should not also be able to send messages or move files without your approval.

Which actions should the assistant take alone, and which need you?

Permissions are about access. Approval boundaries are about action. You need both, and the second is easier to set up in a solo practice because the approver is always you.

Use this decision guide for each action the assistant could take, sorting it into one of three groups:

• Allowed alone: reversible, internal and low in consequence. Examples: creating a draft in your own folder, summarizing a document, preparing a brief, adding a private note.
• Needs your approval: anything that leaves your practice or changes a record someone else relies on. Examples: sending an email, sharing a file, accepting or moving a meeting, editing an invoice, updating a client-facing document.
• Never allowed: actions where a mistake is hard to undo or carries legal or financial weight. Examples: deleting source files, signing or agreeing to terms, making payments, contacting a client's counterparties on its own.

Write the three lists in the same document as the role description. When you want to move an action from the second group to the first, treat it as a deliberate change: do it only after you have watched the assistant handle that action correctly over a run of real cases, and note the date and the reason. A short, regular check of who and what has access keeps these lists honest, and How to Run a Permission Review for Your AI Agents, Step by Step gives a method you can shrink to fit one person.

Two small controls round this out. Set a usage or spending ceiling with your model provider so a loop or a mistake cannot run unnoticed. And keep a simple log of what the assistant did, even if it is only a running list of actions in a document. You do not need a monitoring platform. You need to be able to answer what happened on Tuesday.

What does a month of running it look like? An illustrative scenario

The following is an illustrative scenario, not a report of any real engagement.

Imagine an independent operations consultant who serves a few small clients. She chooses one role: after each client call, the assistant turns her raw notes into a summary and a list of follow-ups. Her success test is that she can send the summary after light edits, and that it never records a commitment she did not make.

She writes a one-page practice profile, adds three of her past summaries as style examples, and creates a short note for each client. She connects two things only: the folder where she saves call notes, with read and write access limited to that folder, and a drafts area in her email, where the assistant can save a draft but not send. Sending stays with her. Deleting anything is never allowed.

In the first weeks she reads every summary closely and keeps a list of corrections: a client's name spelled wrongly, a deadline mistaken for a target, a tone slightly too formal. Each correction goes into the practice profile or the client note rather than being fixed only in the draft. By the end of the month the corrections slow down, and she sees a pattern: the assistant struggles when her notes are fragments. She changes her own note-taking habit slightly instead of adding a new tool.

On the first of each month she spends a short sitting on a standing checklist:

• Read the action log and look for anything unexpected.
• List every connected tool and confirm each is still needed.
• Check that access for any finished client engagement has been closed.
• Review the corrections list and update the memory documents.
• Decide whether one approval boundary should move, and note the reason.

Nothing in that routine is sophisticated. Its value is that it happens on a schedule rather than when something has already gone wrong.

How Be Human's managed approach handles this

Be Human designs, implements and operates personalized AI infrastructure, and a first engagement defines one useful role, the memory and tools it needs, approval boundaries and an observable success criterion. For a one-person practice that means the same sequence described above, with the setup built and documented for you rather than assembled in spare hours. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The work is done remotely, in English and Portuguese, and the assistant stays under your control: you decide what it can access and what it must ask about first. If you are weighing whether to assemble this yourself or involve a partner, Avoid AI Vendor Lock-In With Business Agents lists questions worth asking either way, such as who owns the memory documents and whether you can take them with you.

Frequently asked questions

Do I need custom software, or can I start with the tools I already use? You can usually start with what you already have, as long as you can control its access, see what it did and export your memory documents. The decisions in this article (one role, small memory, narrow permissions, approval rules) apply regardless of the product. Move to something more tailored when you hit a limit you can name, such as needing the assistant to work across several channels with consistent rules.

How much of my client information should the assistant hold? Hold only what the chosen role needs, for as long as the engagement needs it. Keep a short note per client rather than full archives, check your client agreements for any restriction on where information may be processed, and close the client section when work ends. If you are unsure whether a client would be comfortable with a given use, ask them or leave that material out.

When can I let the assistant send messages on its own? Only after you have watched it handle that specific kind of message correctly across a run of real cases, and only for messages that are low in consequence and easy to correct. Start with drafts that you send yourself. If you do grant sending rights, limit them to a narrow category, keep a log, and plan to review the decision at your next monthly check.

How do I know the setup is working? Return to the success test you wrote at the start and check it against real output. Are the drafts usable after light edits, and are the facts correct? Add a second signal from the log: has the assistant ever tried something outside its role? If the answers are yes and no respectively, the setup is doing its job, and you can consider adding a second role.

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