Levels of AI Customization for Business: Prompts to Harness

AI customization for business has four levels. Prompts shape how the AI behaves, knowledge grounds its answers in your company material, tools let it act inside your systems, and a harness governs memory, permissions, approvals and monitoring around all of it. Most problems need only the lowest level that solves them. The right level depends on what the AI must know, do and be trusted with, not on how ambitious the project sounds.

Key takeaways

• Customization is a ladder, and each level adds capability and responsibility. Start at the lowest level that fixes the actual problem.
• Prompts change behavior, knowledge changes what the AI can answer from, tools change what it can do, and a harness changes how safely and reliably it can do it over time.
• Wrong answers about your company usually point to a knowledge problem. Missing actions point to a tool problem. Unpredictable or unsafe behavior points to a harness problem.
• Every step up needs an owner, a way to measure whether it works, and a way to undo it.
• Skipping levels is the common mistake: connecting tools before the knowledge is clean, or granting access before approval rules exist.

What are the levels of AI customization?

Think of the ladder as four questions, asked in order.

• Prompts: how should the AI behave, sound and format its work?
• Knowledge: what company material should it answer from?
• Tools: what should it be able to look up or change in your systems?
• Harness: what keeps it identifiable, remembered, permitted, observed and correctable?

The levels are cumulative. A tool-using agent still needs good instructions and good knowledge. A harness without a role worth governing is overhead. The ladder is also not a maturity score to climb for its own sake. A company that answers repeated internal questions well at level two has made a sound decision, and nothing about that is a lesser result.

For how these levels sit inside a broader stack, see The Seven Layers of Company AI Infrastructure, Explained.

Level one: what can prompts and instructions do?

A prompt is the written instruction the model receives before it starts: the role, the tone, the format, the rules of thumb, the things to avoid. It is the cheapest level and the fastest to change, which is why every team starts here.

Prompts handle a surprising amount of work when the task is self-contained. Drafting a customer reply in your house style, summarizing a document someone pastes in, turning rough notes into a structured report: the model needs only clear direction and the material in front of it.

Prompts stop working when the answer depends on facts the model was never given. No instruction can make a model recall your returns policy, your supplier terms or last quarter's process change. Longer prompts also become fragile. When instructions grow into pages of exceptions, small edits cause surprising side effects, and nobody remembers why a rule exists.

Signs you have outgrown level one:

• People paste the same reference material into every conversation.
• The instructions keep growing and contradict themselves.
• The AI sounds right but states company facts that are wrong.
• Results differ depending on who wrote the prompt.

The reach and limits of a packaged prompt-plus-files setup are covered in Custom GPT for Business: What It Does Well and Where It Stops.

Level two: how does knowledge change what the AI can answer?

The second level gives the AI access to your own material at the moment it answers. The usual technique is retrieval: the system finds the relevant passages in your documents and places them in front of the model along with the question. The model then answers from that evidence instead of from memory.

This is where most business value starts, because most business questions are about the business. What is our policy on late deliveries? Which version of the onboarding checklist is current? What did we promise this customer?

Knowledge work is mostly editorial work, not technical work. Retrieval returns whatever your documents say, including outdated drafts, contradictions and unwritten exceptions. The practical tasks are:

• Decide which sources are authoritative, and who owns each one.
• Remove or mark superseded documents.
• Set a review rhythm so the material does not decay.
• Decide what the AI should say when it finds nothing: admit it, and route to a person.

A question people often ask here is whether to train or fine-tune a model on company data instead. Fine-tuning adjusts a model's habits, such as style or specialized output patterns. It is a poor way to keep facts current, because facts change and retrained weights are hard to correct or audit. The AWS guidance on comparing retrieval and fine-tuning draws the same line: retrieval for changing knowledge, fine-tuning for consistent behavior in narrow cases. For most companies, fine-tuning is a late and optional step, not a rung everyone must climb.

Level three: what changes when the AI gets tools?

Tools turn an assistant that talks into an agent that works. A tool is a defined action the AI may take: search the order system, read a calendar, create a draft invoice, update a ticket, send a message. The model decides when to call a tool, and your systems carry out the action.

This changes the risk profile. A wrong answer is an inconvenience. A wrong action is an event. So tool design matters as much as model quality. Good tools are narrow, clearly named, return clear errors, and do one thing. A tool called "update customer" that can change any field is a liability. A tool that can only add a note to a ticket is easy to reason about. Anthropic's guidance on writing tools for agents makes the same point from the engineering side: tools are an interface designed for a model, and their clarity directly affects how well the agent uses them.

A sensible order for introducing tools:

• Read-only tools first, so the agent can look things up without changing anything.
• Draft-only tools next, where the agent prepares an action and a person confirms it.
• Write tools last, limited to specific fields, records and amounts.

Each tool should have its own credential with the smallest permission that works, not a shared administrator login. The routine for checking this is in How to Run a Permission Review for Your AI Agents, Step by Step.

Level four: what is a harness, and when do you need one?

The harness is everything around the model that makes it a dependable team member rather than a clever demo. It covers the parts that persist beyond a single conversation:

• Identity: a named role with a defined purpose and a place in your organization.
• Memory: what the agent retains between tasks, where it is stored, and how it is corrected or erased.
• Channels: where people reach it, and who is allowed to.
• Permissions and approval boundaries: what it may do alone, what needs a human yes, and what it must never do.
• Observability: logs and traces that show what it saw, decided and did.
• Evaluation: a standing set of test cases that catches regressions when anything changes.
• Operations: monitoring, incident response, and controlled updates.

Anthropic's writing on harnesses for long-running agents describes why this layer exists: an agent working across many steps and sessions needs structure to keep its state, progress and checks consistent, or it drifts. Their broader guidance on building effective agents also recommends starting simple and adding complexity only when it clearly helps.

You need a harness when any of these are true: the agent acts on real records, more than one person depends on it, it handles sensitive data, a mistake would be costly to reverse, or it must keep working after the person who set it up moves on. Many companies reach this level without noticing, because a tool-connected agent in daily use is already operating without one.

Which level does your problem need?

Use the symptom, not the technology, to choose. Match what is going wrong to the lowest level that addresses it.

• Output is right in substance but wrong in tone, length or format: level one.
• Output is fluent but wrong about your products, policies or history: level two.
• Output is right but people still copy results into other systems by hand: level three, starting with read-only tools.
• The agent works in tests but nobody can say what it did last week, who approved it, or what happens if it fails: level four.
• The agent behaves differently after every change and nobody can tell if it got better: level four, specifically evaluation.

Illustrative scenario: a distribution company wants an assistant for its customer service team. At level one, a good prompt fixes the tone of replies, but the assistant invents return conditions. At level two, the team connects the current returns policy and shipping terms, and the invented answers stop, with an explicit "I could not find this" for gaps. Staff still look up order status by hand, so at level three they add a read-only order lookup. Later, someone proposes letting the assistant issue small goodwill credits. That is the moment for level four: a spending limit, a human approval above it, a log of every credit, and a test set that runs before any change goes live. Nothing in the story needed all four levels on day one.

Before deciding, write down the role in plain terms. Write a Job Description for Your First AI Agent Role shows how, and How to Define Success Criteria for an AI Agent Pilot helps you decide how you will know the chosen level is enough.

How does Be Human handle the ladder?

Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the knowledge and tools it needs, its approval boundaries and an observable success criterion. That scoping step is what places the work on the ladder: if a level-two setup solves the problem, the engagement stays there. Where tools or a full harness are justified, Be Human builds and then operates them, with monitoring, recurring evaluations, integration maintenance, permission review and controlled improvements, remotely and in English or Portuguese. The company keeps control of approvals and access throughout.

What mistakes do companies make on the ladder?

The patterns are consistent enough to name.

• Skipping knowledge. Teams connect tools to a model that still gives wrong answers about the business, so mistakes now have consequences.
• Treating the harness as optional polish. Approval rules, logs and tests are added after the first incident rather than before the first action.
• Customizing in the prompt what belongs in the knowledge base. Policies copied into instructions go stale silently.
• Giving broad access for convenience. A single powerful credential saves an afternoon and creates a standing risk.
• Measuring nothing. Without a baseline and a success criterion, no one can say whether a higher level improved anything.

A useful habit is to treat every move up the ladder as a pilot with an exit. The stages and what each must prove are laid out in Proof of Concept, Pilot or Production: What Each AI Stage Must Prove.

Frequently asked questions

Do we need all four levels? No. Many useful deployments stop at prompts plus knowledge. You add tools when the work requires action in your systems, and a harness when the agent's actions matter enough that you need control, evidence and continuity.

Is fine-tuning a separate level? It is better seen as a side path. Fine-tuning shapes consistent behavior or style in narrow cases, while retrieval handles facts that change. Most companies get further by improving their knowledge sources and tools first.

How do we know we are at the wrong level? Look at the failures. Wrong tone points down to prompts, wrong facts point to knowledge, manual copying points to tools, and unexplained or unsafe behavior points to the harness. If you cannot describe the failures, start by collecting a dozen real examples.

Can we move up the ladder later without starting over? Yes, if the lower levels are kept clean. Well-owned documents, narrow tools and written approval rules carry forward. A change to a live agent should still be tested and reversible, so each step up is reviewed before it reaches people who depend on it.

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