Custom AI agents for business: choose the process

A custom AI agent uses language models, workflow logic and approved tools to complete defined parts of a business process. The useful scope states what enters the case, which sources the system may read, which action it may prepare, when a person decides and what trace remains.

The first question is therefore the process. A named inbox case, invoice exception, support ticket or document pack can be tested. A department label such as “automate sales” cannot.

Select a process with a real owner

Choose work with recurring inputs, a visible handoff and enough volume or consequence to justify engineering. Write the current flow in cases:

• what starts the case;
• which data is required;
• which outcomes are routine;
• which conditions require review;
• what system records completion;
• who owns exceptions and future changes.

Use a baseline from the team's own records. Count cases, handling time, correction effort, missed deadlines and the work that remains after a proposed automation. A business case should use that baseline rather than a generic productivity promise.

Give the agent a process contract

The contract should cover seven elements:

1. Work: the case and its expected volume.
2. Context: the sources and fields available to the system.
3. Tools: APIs, files, queues and permitted operations.
4. Result: the fields or drafts the system may produce.
5. Stop condition: cases sent to a person.
6. Owner: the role that accepts an exception or incident.
7. Trace: source identifiers, policy version and action history.

Pass structured records between steps. Keep source locations with extracted values and attach a reason to every hold. The process owner should be able to inspect a case without relying on the model's explanation alone.

Compare an agent with simpler layers

RPA follows fixed interface actions. A workflow platform connects services and evaluates rules that have already been written. A custom agent adds interpretation when inputs vary and the next step depends on context. A ready SaaS product may be the best purchase when it already covers the process and its governance requirements.

Start with the smallest option that meets the process contract. A model in a workflow may solve classification or drafting without requiring an agent that selects actions.

Keep people at consequential steps

Money movement, contractual language, employment decisions, sensitive records, public communications and irreversible writes need a named review action. The agent can gather context, prepare a draft, show sources, update low-risk fields and route the case.

Set permissions per operation. Read access can support preparation and remain logged. Draft creation can be automatic while sending requires approval. Writes can be restricted by field, value or confidence. A review card should contain the evidence and the question the operator must answer.

Test with a representative case set

Build an acceptance set before tuning the workflow. Include routine cases, missing fields, duplicate records, contradictory sources, long threads, unusual formats and a service outage. Have an owner record the expected result, allowed action and hold reason for each case.

Run in shadow mode when a wrong release is hard to reverse. Measure accepted-result quality, correct holds, messages released against policy, correction effort, review time, trace completeness and cost per case. Keep configuration cases separate from the final evaluation set.

Price the first implementation

Syntalith lists single-process automations from €3,500 net and broader apps or agents from €6,000 net. The quote follows integrations, data preparation, access controls, state, evaluation, monitoring, deployment and support. Model usage, hosting and change work remain operating lines.

monthly value = assisted cases × minutes saved × loaded minute cost
                + avoided correction cost
                - review, model and infrastructure cost

Use the company's measured volume and correction work. A table of assumed minutes is a planning aid; the first pilot should replace assumptions with observations.

Build in a controlled sequence

1. Map one case type and its source systems.
2. Write the permitted result, holds and approval roles.
3. Prepare the acceptance set and baseline.
4. Connect read operations and produce reviewable drafts.
5. Add low-risk writes only after quality and trace checks pass.
6. Run a limited production slice with monitoring and rollback.
7. Review the owner workload before expanding the scope.

The shared-inbox case illustrates a useful pattern: code-based policy decides which routine messages may proceed, while money, contracts, complaints, negotiation and uncertain classifications go to a person. The case provides an implementation reference; your workflow still needs its own acceptance set.

Decide whether custom work is justified

Custom development fits when the process has recurring volume, varied input, system integrations, measurable correction cost and an owner who can review exceptions. A workflow, SaaS product or manual checklist fits when the cases are rare, rules are fully deterministic or a ready product already meets the required controls.

Before signing a build, ask:

• What exact case will the system own?
• Which values must retain a source?
• Which tools can it call and which actions are forbidden?
• Who approves a send, write or escalation?
• What happens when a model or integration is unavailable?
• How will the company measure correction and review work?
• Who maintains policy, credentials and integrations?

If those answers are available, bring the process to a free process scan. Syntalith can return a first scope and indicate whether the sensible purchase is a workflow, app or custom agent.