OrderToWork

An AI workbench for made-to-order businesses. Built with Strands Agents, it checks customer changes, captures exact approval, and connects agreed orders to production tickets and customer handover.

Comment

Inspiration

“Can we add fifteen more and collect earlier?”

For a made-to-order business, that small request can change stock requirements, production capacity, price, and the customer's agreement. The owner has to work out what is possible, get the revised terms approved, and make sure the team produces the right version.

I built OrderToWork around that gap between a customer conversation and the work people must deliver. It gives small teams a shared view of what was requested, what can be offered, and what the customer actually accepted. Custom merchandise and made-to-order bakeries are the first two implemented business profiles.

What it does

OrderToWork carries a customer change through a complete business workflow:

  1. Understand the request. Record the customer's message. A Strands run interprets the change using current order facts and keeps source evidence visible.
  2. Check what is feasible. Application rules calculate prices and check stock and dated production capacity. The owner compares checked alternatives while the existing agreement stays intact.
  3. Get exact approval. Share a private customer link for one proposal. The customer reviews its specifications, pickup, price, and deposit requirement. Approval rechecks availability before replacing the reservation in one transaction.
  4. Release the right work. Production requires the accepted revision, reserved resources, sufficient recorded deposit, and no blocking hold. The production ticket carries that agreed version.
  5. Arrange customer handover. When work is finished, prepare collection instructions, a delivery policy, a customer link, and notification text. The customer chooses collection or requests delivery; any delivery quote needs explicit acceptance of its fee, address, and terms.
  6. Record completion. After the remaining balance is recorded, the business marks the order collected or out for delivery and delivered. The history connects these actions to the accepted order.

The recorded demo begins with 30 navy shirts for $540. Adding 15 medium shirts and moving pickup earlier exceeds stock and capacity. A checked alternative offers 45 charcoal shirts at the original pickup for $810, with a $135 deposit top-up. The customer approves those exact terms before work proceeds. Later, they accept a $5 delivery fee, bringing the final total to $815.

All demonstration data and receipts are synthetic. Receipts record money received elsewhere; OrderToWork does not process payments. Notification text is prepared for manual sharing, and delivery statuses are business records rather than courier tracking.

How I built it

The interface uses React and TypeScript, backed by FastAPI and PostgreSQL. Saving a customer message also creates a durable analysis job. A separate worker claims that job, runs the agent, and persists valid results only if its lease and the order revision are still current.

The agent uses Strands Agents with Qwen3 235B A22B on Amazon Bedrock Mantle. Two scoped application tools connect language interpretation to business facts:

  • read_order_context supplies the invocation's current order and business context through Strands.
  • preview_change checks proposed terms against the application's authoritative pricing, stock, and capacity rules.

The coordinator primes the context tool, and the agent produces a structured interpretation with source quotes and missing details. The application validates the result and ensures the final terms have been checked. Agent tools can read and preview; they cannot approve orders, record receipts, or start production.

PostgreSQL row locks and transactions protect approval, reservation replacement, receipts, and handover transitions. Exact revision and quote checks prevent a stale action from silently replacing newer terms. Model inference happens outside the database transaction.

The AWS deployment uses Cognito for business sign-in, private S3 for files, invocation snapshots and backups, and an ARM EC2 host running Caddy, the API, the worker, and PostgreSQL through Docker Compose. The worker uses scoped IAM credentials for short-lived inference tokens. Strands' OpenAI-compatible adapter connects to the AWS Mantle endpoint; the model runs on Amazon Bedrock.

Challenges I ran into

A request is easy to misinterpret as permission. “Navy if possible” leaves room for an alternative, but the customer must still approve a different color. I made source evidence, proposed terms, and accepted terms distinct throughout the interface.

Availability can change between a preview and approval. Checking once is insufficient when another order can consume the same resources. Approval therefore rechecks availability under database locks and replaces reservations atomically; an unavailable replacement preserves the previous commitment.

The agreement must survive every handoff. Owner review, customer consent, production, and delivery need different screens and permissions. Keeping them tied to the same accepted revision became the central design decision. Delivery-fee consent also binds the customer to one exact quote instead of a changing total.

Model access required a practical AWS integration change. When the initial Bedrock runtime path was unavailable to the account, I integrated the working Mantle endpoint while retaining Strands and AWS-hosted inference. Bounded agent runs and a single-host deployment helped keep the live demonstration affordable.

Accomplishments I am proud of

  • A deployed workflow that goes from a fresh Strands execution to checked alternatives, customer approval, a production ticket, and completed customer handover.
  • An execution record showing the actual model, tool activity, source evidence, and reported usage. Prepared examples and new live analyses are visibly distinguished.
  • A recorded merchandise walkthrough that finishes with the accepted revision, delivery consent, a zero sample balance, and a delivered order.
  • Merchandise and bakery profiles sharing the same workflow with different specifications and resource units.
  • Automated coverage for consent, stale revisions, concurrency, job leases, deposits, role boundaries, and handover, alongside browser checks of the real application.

These are functional results with synthetic data. I have not yet measured customer adoption, time savings, or error reduction in operating businesses.

What I learned

A useful business agent needs a clear connection between language, current facts, and authorized action. Exposing that connection improves both reliability and usability: the owner can inspect why an option is feasible, the customer can approve precise terms, and an operator can see which version to make.

The same principle applies after production. Collection and delivery introduce new choices, costs, and consent, so the product needs to preserve the agreement through the final handover.

What's next for OrderToWork

The next step is testing with made-to-order business owners using real, consented requests. I want to measure how quickly they can prepare a feasible revision, whether another team member can identify the accepted version, and where handoff corrections still occur.

That feedback will guide additional business profiles and integrations for messaging, payments, and document interpretation. The current release supports two configured profiles; broader industry coverage needs validation with the people doing the work.

Built With

Share this project:

Updates

Submission history