AI systems

How to Design an AI System for Your Business

Designing an AI system means deciding what work should change, what information the system needs and what it can do on its own. Those decisions give you a basis for choosing a model.

Use this guide to work through the questions that matter when assessing an AI project or defining its scope with a development team.

An evolving guide This guide will continue to grow. It brings together my existing articles on the subject, and I will expand and update it as I publish new work.

Start at the beginning

Start by defining the work that should change

To define a system’s scope, you need to identify the step in the work you want to change. That decision also determines the information the system needs, what it may do and how you will measure success.

Reducing the time a support team spends looking up information is a different goal from resolving a customer’s problem on the first contact. The same model may produce well-written replies in both cases, but you cannot judge success by the same measure.

Start by describing what happens today and what you want to change. Then treat the model’s reply as one part of the work: a system that cannot retrieve the necessary record or hand the task to the right person may fail to deliver the expected outcome, however good its wording. Choose the model according to how well it meets that need.

Start With the Business Problem, Not the AI Model

I explore the difference between a model producing a reply and a system completing the work in this article. It can help you clarify which decisions to make at the start of a project.

A blue target point aligns with two panels and an open tray along a dotted line.

A hypothetical customer support example

Imagine a support team that wants to respond to refund requests faster. The customer may be waiting in each case, but different causes call for different solutions.

Understanding the message takes time: A language model could help identify the request and missing information in an unstructured customer message.
Staff check known conditions manually: Existing software could automate checks against the order date and explicit refund rules.
The decision is made, but approval is pending: If approval is causing the delay, examine decision authority and handoffs first. Writing a response faster will not remove that wait.

An initial scope could be to interpret the request and prepare a draft response for the agent using the order information. Issuing the refund could remain outside that scope. This makes clear what the first version will do and where it will stop.

I explore this distinction in a separate article

When Does Process Automation Actually Need AI?

In this article, I look at Vanity, REDAR and bank integration to explain which tasks were handled by business rules, an integration service or a language model. These examples can help you assess where your own process needs AI.

A workflow sorts standard documents by rules while a crumpled page branches to a magnifier.

How will the system get the right information?

Drafting a reply to a refund request takes more than the customer’s message. The return policy, current order status and a customer-specific agreement may all affect the answer. Identify the source of each piece of information and how current it needs to be.

Explaining a return policy and deciding whether a particular order meets its conditions require different information. The policy text may be enough for the first task. The second may also need the delivery date, product details and customer-specific terms. An accurate document does not mean those records are available and up to date.

Assess data readiness for a specific decision: what is missing, which answer or action does that gap affect, and who is responsible for keeping the information current? In some cases, fixing the source is the right next step; in others, narrowing the scope of the first version may be more appropriate.

Is Your Data Ready for AI? Start With the Decision It Must Support

In a separate article, I examine how the decision determines whether the data is sufficient. The examples can help you work out which gaps to address first.

A blue probe marks the missing information support beneath a decision plate resting on four others.

The same hypothetical refund request, three information needs

Under what conditions can this product be returned?: The applicable return policyIf the relevant rule is short and you know which document contains it, providing the current text alongside the question may be enough. A separate document search system may add little.
When was the order delivered?: The current record in the order systemGet delivery information through an authorized system query rather than an old document copy. An API or database connection can provide that current record.
Does this customer have special terms?: The customer record and relevant contractFinding the right passage among many contracts may require search. Verify the customer match and access permissions before the information reaches the model.

RAG retrieves relevant source material and adds the passages to the model’s context before it answers. It can help locate the right passage in a large document collection; it serves a different purpose from looking up a current order record.

If required information is missing or its freshness cannot be verified, asking for it or handing the task to a support agent is also part of the design. Decide in advance how the system should proceed in those cases.

I compare these information access options in a separate article

When Does Enterprise AI Actually Need RAG?

Using a maintenance manual, a current order and a customer contract, I examine when to provide a document directly, query a system or use RAG. The article explains when search is useful and where access permissions need to be enforced.

A document lens, live data gauge, and locked archive represent three information paths.

Providing the model with the current return policy does not retrain it; when the policy changes, you update the source. If the model keeps making the same classification or extraction error despite having the right information and clear instructions, adapting it with examples may be worth considering for that narrow task. First establish whether the problem lies in missing information or the model’s behavior.

Does Enterprise AI Really Need Fine-Tuning?

In this article, I use examples to distinguish information, explicit rules and patterns that need to be learned. I also look more closely at when fine-tuning is worth considering.

What can the system do on its own?

A system that understands a refund request and finds the right record can draft a reply. Giving it permission to issue the refund is a separate decision. First decide who chooses the steps, then specify which actions the system is allowed to take.

Who chooses the next step?

Interpret the message, find the order, check the conditions and prepare a draft for the support agent: if the sequence is known, software can manage it. The model interprets the message and writes the reply. This is a workflow; using a model does not mean it has to control the whole process.

Some requests need a different next step depending on what the system finds. A missing order may require a question to the customer; special terms may require checking a contract. If these paths become difficult to define in advance with rules, an AI agent that chooses its next step from a limited set of tools may be worth considering. That flexibility requires more testing and monitoring. It does not automatically grant permission to act.

I explore the workflow–agent distinction in this article

When Do You Actually Need an AI Agent?

Using a customer support example and existing systems, I examine when a fixed workflow is sufficient and where letting the model choose a step can help. The article can help you identify which part of your process needs that flexibility.

A blue selector points to one item in a fixed row of tool stations.

Set action permissions separately

In the same hypothetical refund process, the system could take on three different jobs. These are not features you have to enable in sequence. The first version might only provide information or prepare a recommendation.

Provide information: Explain the return conditions and current order status.Control which customer records the system can access. Access to a record does not imply permission to change it.
Prepare a recommendation: Present the refund amount, reasoning and draft reply to a support agent.The support agent can review, change or reject the recommendation. No refund instruction has been sent to the payment system yet.
Take action: Send a refund instruction to the payment system.Check permissions and business rules for the customer, order and amount when the action is carried out. Do not proceed without any required approval.

What does handing over to a person involve?

If the customer does not match the order, required information is missing or the request exceeds the defined action limits, the system should be able to stop and refer it to an authorized person. The support agent needs the relevant records, proposed amount, reasoning and any uncertainty, not just a summary. They must be able to change, reject or escalate the proposal before the action takes place.

If no response arrives after a refund instruction, do not blindly repeat it. Check the payment record and make sure retries cannot create a second refund. If the status cannot be verified, keep that uncertainty visible and refer the case for review rather than telling the customer their refund is complete.

I examine these permissions and controls in a separate article

How Much Authority Should You Give an AI System?

I look at the difference between a draft, a preview and a real action, when human approval is useful, and how to verify the outcome. Use it to work out where your system should stop and which checks it needs before proceeding.

A blue action proposal passes through a control press before becoming a committed record.

What evidence will tell you it works?

A system can write a correct answer, call the right tool, and still fail to complete the customer’s task. In the returns example, look for answers to four separate questions. The answer to each question is found in a different record.

What did the model produce?: Did it understand the request correctly? Are the proposed amount and response appropriate? Review this using examples that represent real requests and clear evaluation criteria.
What path did the system take?: Which record did it use, did it obtain approval, did it repeat a step? The execution record helps you find the step where an error occurred.
Was the task actually completed?: What is the status of the refund in the payment system? Verify the outcome from the record that holds the transaction; do not count a pending or unknown outcome as complete.
What changed in the business?: Did customers need to contact you again less often? Did the representative’s correction workload change? Assess the business outcome you intended to achieve against the prior state and an appropriate comparison.

Before the pilot begins, write down which outcome, error types, and time period you will track. Do not limit examples to easy requests; include incomplete information, exceptions, and failed transactions. When one indicator improves, also examine other changes, such as the team, period, or mix of incoming work.

The scope of control should grow with the system’s impact. A helper that prepares a draft for a representative does not require the same evidence as a system that moves money. Re-test later changes to the model, information source, or workflow against these examples.

I examine the gap between a good answer and a business outcome in this article

Is Your AI System Actually Delivering Business Results?

Starting with my experience at Camiler.org, I separate the model output, execution record, completed task, and business impact. It can help you define what counts as success in your pilot and what evidence will show it.

Technical success indicators run above an empty drawer for real business results.

What difference would a second model make?

Once the task, information, authority, and success criteria are clear, you can compare model options on the same task. One general-purpose model may be enough to understand the message and prepare a response. Information retrieval, business rules, and payment processing still belong in the other parts of the system.

Give the second model a specific task, such as classifying frequent requests. Does it improve quality, speed, or cost on real examples? A specialist model may be useful for a narrow task, but the gains must also justify the additional integration, testing, and maintenance.

Do not end the price comparison at the model call. Consider the costs of the model, controls, error correction, and operations together, and relate them to the number of usable outcomes. Test in advance whether a model added for resilience can also perform the same task at an acceptable quality level.

I examine the limits of a single model in this article

When Is One AI Model Enough?

I discuss when starting with a general-purpose model is reasonable and how a specialist model can earn its place. You can assess the benefit of a second model alongside the operating burden it brings.

A versatile main mechanism sits beside a specialist module for narrow, repetitive work.

If you have multiple models, how will you route the request?

Needing a second model does not mean you need to build a predictive system that selects a model for every request. If the document type, an explicit business rule, or data policy already determines the choice, apply those boundaries first. The following approaches solve different problems.

Fixed rule: The choice is known before the call. For example, a scanned document goes to a model that can process images. Software applies the rule and its exceptions.
Prediction-based routing: The router predicts which model suits the request. Sending a difficult request to an inadequate model is a separate error type, so you also need to measure routing decisions.
Escalation path: The adequacy of the first response is checked, and another model is tried if needed. The second call and evaluation add to cost and waiting time.
Fallback path: A pre-tested alternative takes over during a technical error or outage. The fact that the first model responds but gives a wrong answer does not automatically trigger this path.

If you try a prediction-based router, run the same requests with a single model and with simple rules as well. Compare not only the call price, but also misrouted requests, total latency, and cost per usable outcome. An additional decision layer earns its place only if this comparison shows a meaningful difference.

I compare routing options in a separate article

How Should You Route Requests Across Multiple AI Models?

I unpack the differences between fixed rules, prediction-based selection, escalation paths, and fallback paths with examples. You can look more closely at the comparisons to make before adding a router.

Varied request cards pass through a calibrated selector before reaching separate destination trays.

What will make the system specific to your company?

The same model may explain a return policy in one company; in another, it may find the order, check customer-specific conditions, and produce a proposed transaction ready for approval. The difference comes from the sources it connects to, the rules it applies, and the authority it is given, alongside the instructions supplied to the model.

Keep the current order record in the order system, explicit return rules in software, and access and transaction authority in the relevant controls. The model can use these parts; it does not take responsibility for them. If it needs to learn a company-specific pattern, evaluate that separately with real examples.

When the model changes, you should be able to re-test the outcome using the same sources, transaction limits, and evaluation examples. Who updates the source, decides an exception, and follows up a failed transaction are also part of the design. This prevents operational knowledge from being lost in a single prompt.

I examine how these parts come together in the final article

What Makes an AI System Specific to Your Business?

Using a purchasing example, I examine where information, rules, tools, authority, and measurement should sit. You can distinguish what the model needs to learn from what the surrounding system needs to provide for your specific use case.

A blue model cartridge sits inside a larger mechanism for data, rules, authority, and verification.

Turn the first version into a short decision brief

By the end of the guide, you should have a scope you can discuss with the development team rather than a list of models. The example below describes only the first, draft-preparing version of the hypothetical returns process we have used; it is not a promise of an outcome or performance.

The work we want to change: Reduce the time the representative spends finding information when preparing a return response, while tracking response accuracy and correction workload together.
The boundary of the first version: Understand the request and prepare a response draft with its sources. Sending it to the customer and issuing the refund remain in the representative’s existing process.
Information and access: The current policy, authorised order lookup, and customer-specific conditions where needed. Incomplete or conflicting information is shown clearly to the representative.
How it works: A predefined workflow and one model to be tested on real examples. An agent, fine-tuning, or a second model requires evidence of a specific deficiency first.
Success and stopping criteria: Time and quality are recorded before the pilot; the team defines test examples, acceptance thresholds, and the evaluation period. Unauthorised data access or a growing correction workload blocks expansion.
Ownership and maintenance: Identify the person who updates the policy source, the representative who handles exceptions, and the technical owner who follows up integration failures. Re-test the same examples after changes.

If an item in your own brief still has no clear answer, return to the relevant section. You can keep the first pilot narrow enough to reduce that uncertainty. I will continue developing this guide with questions that emerge from new articles and practice.

Guide sections

Reading list

All articles in this guide

Every article in this guide is collected below, grouped by the decisions it helps you make. You do not need to read them in order; start with the question that matters most to your project.

Are you solving the right problem?

How will the system do the work?

Is the added complexity earning its place?

Where to go next?

This guide opens one part of the decision. These two related topics can help you examine another part of the same decision.