AI Implementation Consultant: Advice or Build? What to Require First

An AI implementation consultant who advises tells you what to build, in what order, and how to judge the result. A builder delivers a working agent with memory, tools, permissions and monitoring that your team then runs. Before you hire either, require written deliverables that show which of the two you are buying, because one job title often covers both.

Key takeaways

• Advice produces decisions, documents and a sequenced plan. Building produces running software that someone must operate after launch.
• Ask every candidate to name the artifacts they will hand over at the end, and who will own each one.
• Do not start a build until the role, its memory and tools, its approval boundaries and one observable success criterion are written down.
• Check who holds credentials, logs, prompts and evaluation sets when the engagement ends.
• Split the contract into an advisory phase and a build phase so each can be judged on its own evidence.

Why the label "implementation consultant" hides two different jobs

The phrase is used for people who run workshops, write architecture recommendations, select vendors and draft governance rules. It is also used for people who connect a language model to your CRM, write the integration code and deploy it. Both can be useful, but they produce different things and carry different risks. An advisor who writes a strong report can leave you with no working system. A builder who starts coding before the business question is settled can leave you with an agent that works well at the wrong task.

The practical test is simple. Ask what the consultant will still be responsible for after the final invoice would have been paid, in plain terms, and what your team will be able to inspect without them. If the answer is "the report" or "the recommendations," you are buying advice. If the answer is "the running agent, its configuration and its logs," you are buying a build. Many engagements need both, but they should be scoped separately so that neither phase can quietly replace the other.

The role description for an advisor is covered in more detail in what an AI implementation consultant actually does. This article focuses on the deliverables that make the difference visible before you commit.

Deliverables to require from an advisor

An advisory engagement should end with documents your team can act on without the advisor in the room. A useful advisory scope produces the following:

• A one-page map of the current systems, data sources and decision points, showing where an agent could read or write. A related format is described in how to draw your AI stack on one page.
• A ranked list of candidate roles, with a written reason for including or excluding each one.
• A data and permission inventory for each candidate role: which systems it would touch, what data it would see, and which accounts would be used.
• A draft of approval boundaries, naming the actions that always need a human decision.
• One proposed success criterion per candidate role, written so that someone outside the project could check it.
• A list of risks with an owner for each, and a recommendation that says whether to build, pilot, wait or stop.

Notice what is missing from that list. A good advisory deliverable does not contain code the advisor expects you to deploy, and it does not depend on access to your production systems. If an advisor insists that the recommendations can only be understood with their running environment, treat that as a sign that the advisory and build work are being mixed together.

Deliverables to require from a builder

A builder should hand over a system and the evidence needed to operate it. Ask for these items in writing before the build begins, and confirm them again at handover:

• A role definition: the single job the agent performs, its inputs, its outputs, and the person who owns its results.
• A memory and tool inventory: each tool the agent can call, whether it reads or writes, the exact scope granted, and who approved that scope.
• Approval boundaries: each action that requires a human sign-off, with the condition that triggers it.
• An evaluation set: representative tasks, expected outcomes and the pass criteria, kept in a form your team can rerun.
• Run records: a way to see each request, the tool calls made, the outputs produced and the errors raised. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains why traces, metrics and logs are needed to understand a system's behavior after it is in use.
• A handover package: configuration stored in an account you control, a list of credentials and who holds them, a runbook for incidents, and a tested backup and restore procedure.
• A statement of who maintains the agent after launch, what that covers, and how changes are requested and approved.

If a builder cannot describe these items in concrete terms, they are probably planning to keep the system's operating knowledge in their own hands. Your contract should make the handover a named deliverable with a date, not a courtesy. The contract structure for these items is laid out in what to put in an AI agent statement of work, section by section.

A decision guide: which one do you need first?

Use the following sequence to decide what to buy first. It is deliberately conservative, because the most expensive mistake is building an agent for a process nobody has examined.

• If you cannot yet name the process an agent would support, hire advice first and keep the scope to discovery.
• If you can name the process but not the data it depends on, add an advisory step that inventories systems and permissions before any build.
• If the process is repetitive, has a clear output and has a measurable success criterion, scope a build for one role only.
• If you have no internal person who can own the agent's results, include managed operations in the plan from the start, not as a later addition.
• If the same firm would both advise and build, require that the advisory document be reviewed by someone on your side who did not write it.

Illustrative scenario: a regional distributor wants an agent to answer supplier order status questions. The advisor maps three systems and finds that two of the tools the agent would need can write records, and nobody on the operations team can currently review who has write access. The recommendation is to start with a read-only role, a short evaluation set built from real questions, and a permission review before any write action is considered. The build that follows is smaller, and the decision to add write access becomes a separate, documented choice.

Check permissions, tools and injection risk before the build starts

Most early agent failures are not about model quality. They come from tools that were granted more access than the task needed, or from inputs that were trusted when they should not have been. Before any builder writes integration code, ask for a written account of how each tool is authorized and what happens when the agent receives content that tries to change its instructions.

The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes the basic principles: deny by default, grant the smallest permission that completes the task, and check authorization on the server side for every action. Those principles apply directly to an agent that calls tools on behalf of a user or a team. A builder who proposes a single shared account with broad rights for convenience is asking you to accept risks that are easy to avoid at design time.

For prompt injection, the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a useful reference list for the questions to ask. Require the builder to explain which inputs the agent treats as data rather than instructions, which tool calls need confirmation, and how the team will learn that an agent behaved unexpectedly. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) gives a broader vocabulary for mapping and managing these risks across the life of the system, which is useful when the advisor and builder are different firms and need a shared reference.

Questions to ask in the first meeting

The first conversation with any candidate should reveal which kind of firm you are speaking with. Ask the following and listen for specifics rather than general confidence:

• Which artifact will you give me on the last day, and who will own it afterward?
• What tool access will the agent have on day one, and what access is explicitly excluded?
• How will I see what the agent did last Tuesday, and who will be paged if it fails?
• Which of your recommendations could I check without you, using only my own team and documents?
• What would make you recommend that we stop, and how would that stop be carried out?
• Who keeps the prompts, configuration and evaluation set if we end the relationship?

A candidate who answers these questions with a clear written scope is usually easier to work with than one who promises results. Be cautious with anyone who avoids the questions about handover and exit, because those are the questions that determine whether you keep control of the system you pay for. For a short list of warning signs in partner selection, see red flags when hiring an AI implementation partner.

How Be Human handles this in its managed approach

Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the memory and tools that role needs, the approval boundaries around it, and an observable success criterion. The advisory questions and the build deliverables are written into the same scope, so the client can see which artifact belongs to which phase and who holds it. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, with each change recorded and approved by the client before it goes live.

Where to start

The most useful first step is rarely a large build. It is a clear written answer to two questions: which single role is worth an agent, and which deliverables you need before anyone writes code for it. Take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

What is the difference between an AI implementation consultant and an AI builder? An advisor produces decisions, documents and a plan, while a builder produces a running system that must be operated and maintained. Both roles can be useful, but they should be contracted separately with different deliverables. Ask each candidate which artifacts they will hand over, and who will be responsible for them after the engagement ends.

What should an advisory engagement deliver before any build? It should deliver a map of the current systems, a ranked list of candidate roles with reasons, an inventory of the data and permissions each role would need, and draft approval boundaries. It should also include one success criterion per role that someone outside the project could check. If those items are not written down, a build is likely to start on assumptions.

What must a builder hand over at the end? A builder should provide a written role definition, a tool and memory inventory with the exact scopes granted, approval boundaries, a rerunnable evaluation set, run records that show what the agent did, and a handover package with configuration, credentials ownership, a runbook and a tested backup and restore procedure. The contract should name who maintains the agent after launch and how changes are approved.

How do I know whether I need advice, a build or both? Start with advice if you cannot yet name the process an agent would support or the data it depends on. Move to a build for a single role when the process is repetitive, the output is clear and the success criterion can be measured. Include managed operations from the start if no one on your team can own the agent's results.

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