What makes an AI system useful in a business?

Start with the work

Choose a process your team can describe from beginning to end. What arrives, where does the information live, who makes the decisions, and what counts as finished? These questions give a build a purpose and make it possible to test whether it helps.

For customer inquiries, that might mean bringing together an incoming message, the customer’s history, availability, and your follow-up rules. The system could prepare a response and the next steps for a person to review. The exact actions depend on the agreed connections and permissions.

The parts of a system

An AI model is one part. The surrounding software decides which information to provide, how to use the result, and what to record. Your business rules set the boundaries.

• Information: the records, documents, and messages the work needs.
• Connections: the supported ways to read or update your existing software.
• Business rules: who can access information, which actions are allowed, and where approval is required.
• Applications: the screens and workflows your team uses.
• Support: testing, monitoring, and a way to handle exceptions.

How the system finds business information

Retrieval-augmented generation, often shortened to RAG, means finding relevant information and supplying it to a model when it answers. It can let a system use company documents without training a new model on those documents.

The application might split documents into searchable passages, retrieve the relevant ones, and ask the model to answer from that context. The result can include references to the source passages so a person can check it. Retrieval does not guarantee correctness: missing, outdated, or irrelevant source material can still produce a poor answer.

When custom infrastructure fits

Sometimes configuring an existing tool is enough. A custom build becomes worth discussing when the work needs its own application, connects several processes, or requires rules that the available tools cannot reasonably support.

With a custom build, we write and maintain software around those requirements. Features can change through further development. That still involves engineering work, testing, and agreed costs; writing custom code does not remove every external dependency.

• Explore Custom AI Systems

Choosing and changing models

A system can be designed to work with different AI providers and suitable open-source models. We choose around the task and evaluate changes with realistic examples before switching.

Model behavior, cost, hosting, and operation differ. Provider flexibility is an architectural choice to plan for, with any migration and testing scoped to the project.

Separate provider access from business rules

A provider adapter is a layer of code that translates between your application and a model provider’s interface. Keeping that code separate can make provider changes easier to manage without rewriting every business rule.

Providers can still differ in their supported tools, response format, performance, and data-handling arrangements. A suitable open-source model also needs an operating plan: where it runs, what compute it needs, how access is controlled, and who maintains it. Test a proposed change against the actual work before moving traffic.

Before a system goes live

We walk through the first version with your team, test realistic cases, make adjustments, and agree on permissions. Your team approves it before live use.

• Can the team check the information behind a result?
• Which actions need approval?
• What happens if a connection fails or information is missing?
• Who is responsible for hosting, support, and future changes?
• What are the ownership and handover terms?

• See how a build works

Support the infrastructure after launch

For a custom AI system, support includes investigating bugs and errors, reviewing how connections are behaving, and answering questions about the infrastructure. Openhour also works on cost efficiency within the agreed support scope.

A trace follows one request through its steps. Logs record events and errors. Metrics summarize things such as failures, duration, and usage over time. Together, these can help identify where a request failed or became expensive. Decide what information to record, who may see it, and how long it is retained.

Cost review should look at useful completed work. Avoidable repeated calls, unnecessarily large inputs, or a model that is more expensive than the task requires can be candidates for improvement. Any change still needs testing; lower usage cost is not useful if the team spends more time fixing the results.

• Custom-system support and pricing