How to Build an AI Agent for Business Without Fake Autonomy

Building an AI agent for business starts with a work unit. Framework selection comes later. Choose one queue, record type, document class or follow-up loop. Describe the result, the sources, the allowed actions and the person who approves the outcome. Only then can you decide whether the right implementation is a fixed workflow, a bounded agent loop or a different tool altogether.

An agent adds complexity because it interprets varied inputs and selects among permitted steps. That complexity earns its place when the work has enough repetition and variation to benefit from it. The system still needs a narrow role, a trace and an owner who can correct or stop it.

Step 1: Name the work unit and the done state

Write a sentence that a reviewer can test. "Improve support" is too broad. "Classify refund requests, check the required fields and create a review packet for one queue" can become a build brief.

Define:

• the event that starts the case;
• the record or document the agent handles;
• the sources it may read;
• the output a person expects;
• the conditions for a complete case;
• the conditions that require a stop.

Create a small set of representative cases before coding. Include a normal input, an incomplete input, a conflicting input and a case that should be rejected. These cases become the first acceptance tests.

Step 2: Map the state machine

An agent that touches business systems needs explicit states. A simple intake flow might use received, needs-information, ready-for-review, approved, rejected and closed. Define which transition the agent can propose or execute, who owns each state and what evidence must be present.

State names prevent a prompt from becoming the only process definition. They also make rollback, retries and reporting possible.

Step 3: Map data and access

List every source the agent can read and every tool it can call. Read access and write access should be separate. A system that extracts fields from a document has a different risk profile from one that changes an order, sends a message or approves a payment.

For each source, record:

• owner and system of record;
• fields the agent may use;
• freshness and conflict rules;
• personal or confidential data classes;
• retention and logging requirements;
• failure behaviour when the source is unavailable.

For each tool, record the action, allowed record type, value limit, required parameters, rollback path and approval requirement. Start with the smallest permission set. Add access only after a test case shows why it is needed.

Step 4: Choose the smallest architecture

Use a fixed automation when the sequence, rules and outputs are known in advance. Use a bounded agent loop when the system must interpret an input, choose from a small set of tools and continue until a defined state is reached. Use a human-led assistant when the decision is high-impact or the source quality is still being established.

The model is one component. The application should own state, authentication, permissions, retries, idempotency, timeouts, validation and logging. A model may propose the next action, but application code should check that the action is allowed before calling a tool.

Keep the loop visible:

1. load the case and approved context;
2. ask the model for a structured next step;
3. validate the step against the tool contract and state;
4. call a permitted tool or route to a reviewer;
5. record the result and continue or stop.

Set a turn limit, token budget and timeout. A loop that cannot finish should create a clear exception rather than continue indefinitely.

Step 5: Write contracts for tools and outputs

Give every tool a narrow name and schema. Validate identifiers, enums, required fields and value ranges in code. Make the model return a structured proposal with the reason, source references, confidence or uncertainty and the next state.

Do not let a free-form answer control a production write. The application should reject an unknown action, an out-of-scope record or a missing approval. Keep external communication, payment, contract change and other commitments behind an explicit human gate in the first release.

Prompts still matter, but they are one layer of the contract. Put durable rules in code, schemas and permissions. Keep prompts versioned with the tests that explain what changed.

Step 6: Build the evaluation set before launch

Use the representative cases from Step 1 and expand them as the team sees real failures. For every case, record:

• expected state and allowed actions;
• required source fields;
• facts that must appear in the output;
• conditions that must trigger a stop;
• reviewer decision and reason;
• acceptable time and cost range.

Evaluate both the model output and the workflow. A correct summary is not enough if the agent wrote to the wrong record. A correct tool call is not enough if the source was stale. Measure field accuracy, source coverage, escalation quality, false actions, completion rate, latency and cost per case.

Run the tests after changing the model, prompt, tool schema, source mapping or permission. Keep a versioned record of the result so a later incident can be compared with the release that caused it.

Step 7: Pilot in preparation mode

Start with shadow or proposal mode. Let the agent produce classifications, packets or proposed updates while the existing process remains the authority. Compare the output with the team's decisions and record corrections.

Promote one reversible action at a time. A pilot brief should state:

• the queue and case volume;
• the enabled tools and credentials;
• the reviewer and response time;
• the stop conditions;
• the rollback and pause procedure;
• the measures that decide whether to continue.

Do not widen the scope because a demo conversation looked good. Widen it when the trace, tests and reviewer experience support the next action.

Step 8: Operate and hand over the system

A build is ready for production only when someone can operate it. Document:

• where code, prompts, schemas and configuration live;
• how credentials are stored and rotated;
• which logs are retained and who can read them;
• how alerts, retries and failed tool calls work;
• how a person pauses the agent;
• how incidents and source corrections are recorded;
• who approves model, connector and policy changes.

The NIST Generative AI Profile describes risk work through govern, map, measure and manage. Use the cycle in operations: assign roles, map the use context, measure the controls and incidents, then update the system as evidence changes.

Budget the operating model

Separate the one-time build from recurring work:

First-year cost
= process and technical design
+ implementation and integrations
+ model or API usage
+ hosting, logs and monitoring
+ maintenance and internal review

The estimate should include the cost of source cleanup, test data, access approvals and time from the process owner. If the team cannot provide those inputs, the first purchase may be a specification or process audit rather than a full agent.

Syntalith publishes implementation entry points on its pricing page: specifications from €1,200 net, automations from €3,500 net and apps or agents from €6,000 net. Those figures describe Syntalith's scope; the actual quote follows the work unit, sources, tools and operating requirements.

Common failure modes

• Starting with a framework. The stack cannot decide which actions are allowed or who owns an exception.
• Giving broad credentials. A model can reach records that the process never required.
• Testing only happy paths. Missing fields and contradictory sources are where the workflow needs a decision.
• Treating the prompt as policy. Rules that matter belong in permissions, schemas and application checks.
• No pause mechanism. An owner must be able to stop runs while investigating a source or model change.
• No handoff. A system nobody else can inspect becomes a maintenance risk as soon as the first builder is unavailable.

A practical first build

Choose one queue and produce a one-page brief with the work unit, state machine, sources, tools, approval gate, test set, trace fields and owner. Build the preparation mode first. After the team reviews real cases, decide whether a narrow write or an external action earns a place in the next release.

If that brief is hard to write, the process is not ready for an agent. A free process scan can help decide between a fixed automation, a custom application, a bounded agent and a process change.

FAQ

What should an AI agent do first?

Start with preparation, routing or exception handling for one queue. Give it reliable sources, narrow tools, a reviewer and a clear stop rule before it performs irreversible actions.

Does an agent need a framework?

No. A fixed workflow may be clearer without one. Choose a framework only when it improves a measured need such as state handling, tool orchestration, testing or traceability.

How do we keep an agent from taking unsafe actions?

Separate read and write tools, validate every action in application code, limit records and values, require approval for commitments and keep a pause mechanism. Test incomplete, conflicting and out-of-scope cases.

What should the client own after handoff?

The client should know where code, prompts, schemas, tests, configuration, logs and runbooks live. It should also have a named owner for credentials, incidents, source corrections and release decisions.

When should we buy an automation instead?

Choose an automation when the sequence and rules are stable. An agent adds value when it must interpret varied inputs or select among a small set of bounded next steps.

Related articles

• Agentic AI use cases for business
• How to choose an AI implementation company in Poland
• AI agent implementation cost in Poland
• What an AI agent is
• Syntalith services