Moxie

• 

Inspiration

A small billing problem can consume an entire afternoon. You find a duplicate charge, contact support, navigate a phone tree, repeat your account details, wait on hold, and negotiate a resolution. AI can handle much of that work, but people should still control decisions involving money, contracts, and account changes.

We built Moxie around a simple principle: Moxie makes the call. You make the choice.

What it does

Moxie is an AI support agent that handles the repetitive parts of a customer-service interaction while keeping consequential decisions with the user.

The user gives Moxie a goal and defines boundaries such as:

• No new plan
• No long-term commitment
• No decision without explicit approval

Moxie follows the support workflow, records each important event, and presents the available resolution options with their exact terms. Options that violate the user’s boundaries are blocked.

Approval applies only to the specific offer the user reviewed. If the amount, timing, payment method, or conditions change, Moxie invalidates the previous approval and asks again. After confirmation, it creates a traceable resolution receipt containing the final terms, reference number, evidence, and current settlement status.

How we built it

Moxie uses Strands Agents to give the agent a focused set of tools for progressing through support workflows, interpreting offers, requesting approval, and producing a final receipt.

Anthropic Claude on Amazon Bedrock handles conversation understanding and contextual reasoning. The model can interpret what is happening and decide which tool to request, while the application service controls what actions are actually permitted.

We used FastAPI and Python for the service and API layer. A deterministic state machine manages workflow transitions, approval validity, deadlines, and completion rules. SQLite stores tasks, offers, approvals, evidence, and event history.

This separation lets the model handle language and ambiguity while ordinary application code enforces authority, consistency, and safety.

Challenges we ran into

The hardest problem was defining what approval actually means. A simple approved or rejected flag was not enough. Approval had to be bound to the exact amount, method, timing, conditions, and offer version shown to the user.

We also had to handle changed terms safely. If an approved $80 refund becomes $60, the system cannot reuse the earlier approval. Moxie detects that material change, invalidates the previous decision, and creates a new approval request.

Another challenge was making retries predictable. Agent workflows can receive the same event more than once, so every operation needed idempotent behavior. Repeated requests must resolve to one consistent state without duplicating approvals, receipts, or actions.

Finally, we needed evidence that was useful without exposing unnecessary personal information. Moxie records the events required to explain a resolution while keeping its data boundaries narrow.

Accomplishments that we're proud of

We created an agent that can perform meaningful work without giving the language model unrestricted authority.

We are especially proud of:

• Exact-term approval binding
• Automatic invalidation when material terms change
• Deterministic workflow and permission enforcement
• Idempotent event processing
• User-defined boundaries that block unsuitable offers
• Traceable resolution receipts backed by evidence
• Clear separation between model reasoning and application authority
• A polished interface that makes a complex safety model easy to understand

What we learned

Human-in-the-loop design requires more than adding an approval button. The system must define exactly what was approved, how long that approval remains valid, and which changes require the user to decide again.

We also learned that agent reliability improves when the model receives a small, purpose-built toolset. Claude is most useful when it interprets the conversation and chooses among clear operations. The service layer is better suited to enforcing permissions and valid state transitions.

Most of all, we learned that capable agents do not need unlimited autonomy. They become more useful when the boundary between assistance and authority is explicit.

What's next for Moxie

Next, we want to expand Moxie into a reusable assistant for billing disputes, subscription changes, travel disruptions, appointment rescheduling, and other support tasks that consume time but still require human judgment.

We also plan to add more communication channels, reusable boundary templates, richer evidence timelines, secure identity verification, and integrations with support providers.

Our longer-term goal is to make delegated support work feel normal: describe the problem, define your boundaries, return when a real decision is needed, and receive a clear record of what happened.

Built With

• agentic-ai
• ai-agents
• ai-safety
• amazon-bedrock
• amazon-web-services
• anthropic-claude
• approval-workflows
• customer-support
• fastapi
• generative-ai
• human-in-the-loop
• idempotency
• large-language-models
• pydantic
• python
• responsible-ai
• rest-api
• sqlite
• state-machines
• strands-agents
• uvicorn
• workflow