Bedrock agents or Step Functions: choose the right control

An invoice exception needs interpretation. A payment approval needs a defined authority. Putting both decisions inside an open-ended agent loop makes it harder to explain why money moved.

An AWS workflow can use Amazon Bedrock for the language task and AWS Step Functions for the controlled process. The important design choice is where uncertainty is useful and where the next action must follow an explicit rule.

Write the state transitions first

For a reference invoice workflow, begin with the states a finance owner recognizes: received, checked, awaiting review, approved, and rejected. Name who may authorize each transition. Define which transitions are reversible and which require a compensating action.

This model reveals what the AI should do. It might summarize a discrepancy or extract a proposed supplier identifier. It should not silently acquire the authority to approve a payment because it can describe the invoice convincingly.

Use the model where interpretation matters

Ask the model for a bounded output that the application can validate. For example, return the discrepancy type and the evidence that supports it. Handle missing or malformed fields as a normal failure condition rather than trying to execute a partial result.

The application should check identifiers against the system of record. A model-produced supplier name is a candidate, not proof that a supplier exists or that the invoice belongs to that account. The source system remains authoritative.

Give each tool a narrow contract

A Lambda-backed tool should expose the smallest business operation required by the workflow. Validate its input and check the caller's authority before making a downstream request. Do not expose a general-purpose database command when the task requires a single approved lookup.

Use different permissions for read and write operations. An agent that can inspect invoice status does not automatically need permission to alter it. Keep the write path behind the same business checks used by other authorized applications.

Plan for retries before the first write

A timeout does not prove that a downstream action failed. The action may have completed while its response was lost. Design an idempotency key around the business operation so the next attempt can recognize a completed request.

Also define what the user sees while the result is uncertain. Repeating the entire conversation is a poor recovery mechanism for a process with side effects. The workflow needs a durable execution identifier and an explicit reconciliation step.

Choose the orchestration shape deliberately

Use a defined workflow when the allowed steps are known and the process owner needs to inspect every transition. Consider agent-driven tool selection when the route genuinely depends on interpreting a variable request, while preserving authorization checks around every tool.

Step Functions documents several service integration patterns, including callbacks for tasks that must wait. Select the pattern supported by the service and workflow type you use. Avoid assuming that every integration has identical retry or waiting behavior.

Prove the boundary in acceptance tests

• The model can recommend review without approving the business action.
• An invalid identifier never reaches the write operation.
• A repeated request does not create a duplicate business transaction.
• A timeout can be reconciled without restarting the entire workflow.
• The execution record identifies who authorized the consequential step.

A well-scoped agent makes the process easier to operate. It should not make the source of authority harder to find.

Put one workflow into production

QueryNow scopes AWS AI workflows around your existing systems. We agree the deliverables and acceptance criteria before the build. We build it in your environment. Wider data programs are scoped separately. Tell us the workflow.

Technical references

• AWS: Step Functions service integration patterns