From prompts to a small AI employee

From prompts to a small AI employee

Most firms start AI adoption by asking better prompts. That is useful for learning, but it is not the same as building an operating asset. A prompt is a request. A small AI employee is a role with context, tools, permissions, memory, a goal, and a way to check its own work before a person relies on it.

For a boutique consulting firm, that distinction matters because the valuable work rarely lives in a clean template. It lives in client history, relationship timing, partner judgment, meeting notes, delivery constraints, and the firm language that never quite appears in the public website. The model can be powerful and still fail if the role around it is vague.

The strategic question is not “what can AI do?” The better question is “what junior role would we design if the role had perfect patience, imperfect judgment, and needed clear supervision?” That framing keeps the work grounded. It also keeps the firm from giving a model a vague mandate and then being surprised when the output is uneven.

For the broader model choice, read the pillar guide on frontier and local AI models for boutique firms. This article focuses on the anatomy of the first role.

Context is the onboarding packet

When a person joins the firm, our team would not expect useful work after handing over one sentence of instruction. The person needs the offer, clients, decision rules, standards, examples, and a sense of what good looks like. An agent is similar.

Context can include approved service descriptions, client summaries, call notes, CRM fields, current priorities, internal memos, and previous examples of good output. It should not include every file the firm owns. Too much context creates noise, privacy exposure, and false confidence.

The first design decision is what the role must know to do one job well. A briefing agent may need calendar events, recent inbox threads, and one market feed. It probably does not need payroll, old proposals, or every shared drive folder. Narrow context is not a limitation. It is an operating control.

Tools are the systems the role may touch

A junior employee can only work in the systems they can open. An agent works the same way. Tools may include email, calendar, documents, CRM, task systems, databases, call transcripts, search, or a local model running on a controlled machine.

Tool access should be granted by job, not by excitement. If the role prepares a morning brief, read access may be enough. If it prepares follow-up drafts, it may need document creation but not sending permission. If it watches a feed, it may need scheduled retrieval and no client-system access at all.

This is where many projects become too broad. Teams connect five systems before defining one accountable output. A better first rep has just enough tool access to produce a useful artifact that can be reviewed.

For a concrete first role, see the guide to a daily briefing agent with three sources.

Permissions define the risk boundary

Permission is the business version of authority. What can the role read? What can it write? What can it change? What can it send? What must always be reviewed?

The safest early pattern is read, summarize, draft, and wait. The agent can read approved sources, summarize changes, draft internal notes, and prepare external messages, but a human approves anything that affects a client, prospect, vendor, or public record.

This may sound cautious, but it helps adoption. Partners and operators are more likely to trust a role when they know exactly what it cannot do. Clear limits also make it easier to inspect failure. If the agent produces a weak draft, the issue is quality. If it sends a weak draft, the issue is governance.

Permission rules should be written in business language. “May draft but not send client email” is more useful to a team than a technical access matrix nobody reads.

Memory is what the role carries into next week

Memory is not a dumping ground for every interaction. It is the selected context the role should carry forward. A useful agent remembers corrections, preferences, recurring priorities, known client constraints, and decisions that should affect future work.

In a boutique firm, memory might include a partner’s preferred briefing format, a client’s sensitive topic, a recurring market signal, or a rule like “do not recommend outreach on Fridays unless the matter is urgent.” These are small details, but they are the details that make a role feel integrated rather than generic.

Memory also needs limits. Some information should expire. Some should require approval before it is stored. Some should never be stored because it is too sensitive or too unstable. The role should show what it remembers so the team can correct it.

For a deeper treatment, read memory and self-checks for AI agents.

The goal is the reason to keep the role

A vague goal like “save time” does not create accountability. A better goal is tied to one artifact or operating loop. Prepare a daily partner brief by 7:30 a.m. Flag client follow-up risks before the weekly pipeline meeting. Summarize market changes from one approved feed. Assemble source-backed notes before a proposal review.

The goal should be visible. If nobody can tell whether the output helped, the role will become a novelty. If the output appears in an existing meeting or decision, the firm can judge whether the agent deserves more responsibility.

The goal should also be narrow enough to improve. A broad “AI assistant” can fail in twenty ways at once. A briefing agent can be corrected: missed source, wrong priority, too long, weak citation, unclear recommendation. Correction turns into training data for the operating process.

Self-checks happen before the human review

A useful junior checks work before handing it to a partner. An agent should do the same. Self-checks can include citing the source for each claim, flagging uncertainty, comparing the output against instructions, checking whether a required field is missing, and asking for human review when confidence is low.

Self-checks do not remove human judgment. They make review easier. A partner should not have to inspect every sentence from scratch. The agent should explain what it used, what it could not verify, and where a decision is required.

This is especially important when a firm mixes frontier and local models. A frontier model may produce better writing, while a local model may be used to keep sensitive retrieval inside the firm. In either case, the role should verify its output against approved sources before a human sees it.

Where to go next

Done-for-you implementation assessment For boutique firms that want our team to assess, build, and manage the first agent.

Self-serve AI platform For teams that want to operate their own AI workspace.

Pay-per-run workflows For power users who want low-commitment workflow runs.