Skip to content
AI-accelerated delivery · You pay when it works
Plano, TX · Munich · HyderabadAccepting Q3 2026 briefs
Blog/AWS
July 8, 20263 min read

Bedrock agents or Step Functions: choose the right control

Use Amazon Bedrock for interpretation and AWS Step Functions for explicit process control. Define where an agent can decide and where rules must decide.

Give agents a task.|Keep control explicit. architecture diagram: Interpret request to Validate action to Execute workflow

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. One bounded workflow starts at $10,000, payable only after every agreed criterion is met. We build it in your environment in two weeks. Wider data programs are scoped separately, and AWS usage is separate from the build fee. Tell us the workflow.

Technical references

Take action

Ready to ship AI in your organization?

We build one workflow into a working tool in two weeks. You pay $10,000 only after every acceptance criterion you signed off on is met.

One workflow · Two-week build · $10,000, paid on delivery

Q

QueryNow

QueryNow deploys production AI for enterprises on Azure, AWS, or Google Cloud. Founded in 2014, we help pharma, healthcare, manufacturing, and financial services organizations deploy governed AI systems. We build it, you pay when it works.

Learn more about us →

Share this article

LinkedIn →
Tell us the workflow →
Take the next step

Turn these insights into real results

Point at the workflow your team hates. We build the tool that kills it in two weeks, and you pay only when it works.

The two-week build

We scope one workflow with you and sign an agreement on the acceptance criteria. We build the tool in your environment in two weeks. You see it work before you pay.

  • +A fixed scope and acceptance criteria, signed on day one
  • +A working tool, built in your environment
  • +Automated evaluation against your own data
  • +You pay $10,000 only after every criterion is met
$10,000

One workflow tool. Paid on delivery.

One workflow at a time. $10,000 per build, due only after it meets the criteria you signed.

Keep reading

Related articles

More from AWS