Custom AI agents: how they work inside a business system.

A workflow connects the steps

Think about what happens after a request arrives. Someone reads it, finds the related records, decides who should handle it, and follows up. A workflow describes those steps and the conditions that move the work forward.

Some steps follow fixed rules. Others need help interpreting information or preparing a response. We choose where AI belongs by looking at the work, rather than putting a model into every step.

A workflow follows paths defined in code. An agent can choose the next step and which tools to call as the task unfolds. That flexibility can add complexity, so use it where the work benefits from it. A fixed rule for routing a known request may be enough without an agent.

An agent has a defined job

An agent uses a model and connected tools to work toward a task. In a business system, its job needs clear boundaries: what it can read, what it can change, and when it must stop and ask.

A customer follow-up agent might review a conversation and prepare the next response. Sending that response or changing a customer record is a separate permission. Being able to draft something does not automatically grant permission to act on it.

Give tools a narrow, explicit purpose

A tool is a function the model can ask the application to run, such as looking up a record. Its definition should explain the expected inputs, what it returns, and the conditions under which it is allowed to act. The application must validate the request before executing it.

Keep reading and writing separate when they need different permissions. A tool that finds a customer record can return a limited set of fields. A tool that changes that record should check the caller’s authorization, allowed fields, and any required approval independently of the model’s answer.

Keep people in the right places

Decide which actions can proceed within agreed rules and which require review. A useful approval step gives a person enough context to make a decision and makes it clear what will happen if they approve.

• Show the proposed action and the information behind it.
• Make the pending approval visible.
• Give the team a way to correct or reject the result.
• Record the outcome and handle failures clearly.

Plan for retries and duplicate requests

A connection can time out after a destination system has already accepted a change. Repeating the request blindly could create a second record or repeat an action. Design how the application checks the outcome and retries before enabling live actions.

Idempotency is a common way to make a repeated request have the same intended effect as one request. For example, a destination may accept a stable request identifier and recognize a retry. Support varies by API, so the integration needs its own tested approach to duplicate events, timeouts, and recovery.

Test the awkward cases too

A demonstration should cover more than one successful example. Try missing information, conflicting records, unexpected requests, and unavailable connections. The team should understand what the system does in each case before live use.

We review the first build together, make adjustments, and test against the agreed scope. Training and support help the team use it after launch.

An evaluation should inspect the outcome as well as the explanation. Check that the correct record changed, that a restricted action did not happen, or that a request stayed pending until approval. Run important cases more than once when model behavior can vary, and keep failures as regression cases for future changes.

• Our implementation process

Choose the smallest useful starting point

One well-defined workflow gives you something concrete to evaluate. Broader systems can connect several workflows as the requirements become clear.

We can help configure available tools or build a custom application and infrastructure when the work calls for it. The choice depends on the process, supported connections, and responsibilities your business is ready to take on.

• Compare the two services

Operate the agent as part of your software

A deployed agent still depends on working connections, valid credentials, available models, and an application your team can understand. Someone needs to investigate failures, review changes, and answer questions about the infrastructure.

For Openhour custom builds, ongoing support includes monitoring bugs and errors, improving cost efficiency, and infrastructure questions within the agreed scope. New capabilities and model changes are evaluated before rollout. Hosting, ownership, and handover responsibilities are agreed per project.

• How custom infrastructure is supported
• Discuss a custom build