🧭 Operator
Your AI chief of staff for the work that happens after a customer exists.
Operator is a Strands-powered professional agent for small-business owners. It monitors the business, investigates problems, handles routine operational work, coordinates specialist agents, and brings the founder only the decisions that actually require human judgment.
For the hackathon, Molten Coffee is only the demo business. Operator is the submitted product.
Molten gives us a real Shopify brand, a supplier already connected through Supliful, real lifecycle marketing needs through Sequenzy, and realistic post-purchase workflows. Operator is designed so the same architecture can work for other founder-led businesses.
🎯 The Problem
Once a small business starts getting customers, the founder becomes the manual control plane for everything that follows.
The work is fragmented across systems:
- orders in Shopify
- fulfillment status from a supplier
- customer issues and refunds
- lifecycle email
- repeat-purchase campaigns
- inventory or availability exceptions
- sales and revenue monitoring
- unresolved tasks
- daily decisions that need context from several sources
Most of the normal path is already automated.
For example, if Shopify sends a paid order to Supliful and fulfillment proceeds normally, Operator should do nothing.
The valuable work is in the exceptions:
- shipment delayed
- product unavailable
- customer contacted support twice
- repeat customers stopped reordering
- refund request is unusual
- revenue changed unexpectedly
- a lifecycle campaign is underperforming
- the founder needs a decision, not another dashboard
Operator is designed to handle that messy operational layer.
🧭 Scope: What Operator Owns
Operator is deliberately different from an advertising/growth agent.
It does not buy ads, create Google campaigns, or generate acquisition creatives.
Operator begins where acquisition ends.
It owns:
- Founder briefing and decision triage
- Customer operations and support exceptions
- Fulfillment / supplier exception handling
- Lifecycle and retention orchestration through Sequenzy
- Cross-system investigations
- Human approvals for sensitive business actions
That makes it a true AI chief of staff rather than a generic “business agent.”
🤖 Agent Architecture
The user interacts primarily with Operator, the supervisor agent.
Specialized Strands agents are exposed as bounded capabilities / agents-as-tools so the supervisor can call the right specialist without attaching every tool and every domain prompt to one giant agent.
Founder / Business Owner
│
▼
OPERATOR
Strands Supervisor Agent
│
┌───────────────────┼────────────────────┐
▼ ▼ ▼
Customer Ops Agent Lifecycle Agent Supply / Exception Agent
│ │ │
└───────────────────┼────────────────────┘
▼
Business Analyst
│
▼
Decision / Approval Queue
The specialists exchange structured evidence and actions, not free-form chatter.
🧭 1. Operator — Chief of Staff Agent
Operator owns the full professional workflow:
Observe → Detect → Investigate → Delegate → Prepare → Act → Verify → Escalate
It decides:
- whether a signal is important
- which specialist should investigate
- what evidence is still missing
- whether several systems need to be checked
- whether a safe action can happen automatically
- whether the founder needs to be interrupted
The founder should not have to ask:
“Can you check Shopify, support, fulfillment and lifecycle marketing and tell me what matters?”
Operator should already know what matters.
💬 2. Customer Ops Agent
Customer Ops owns post-purchase customer exceptions.
It can use bounded tools such as:
get_order(order_id)
get_customer_history(customer_id)
get_fulfillment_status(order_id)
search_support_history(customer_id)
prepare_customer_response(...)
issue_small_refund(...)
create_recovery_coupon(...)
Example
Normal order:
Paid → Supliful → fulfilled normally
Operator does nothing.
Exception:
Order #1831
Paid
72-hour fulfillment delay
Customer contacted support twice
Customer Ops:
- retrieves the Shopify order
- checks fulfillment state
- retrieves the customer's prior history
- checks support policy
- determines whether the issue is within an automatic-resolution threshold
- prepares an apology and recovery action
- either resolves it or asks the founder for approval
The goal is not to “answer support questions.”
The goal is to close routine customer problems end-to-end.
📦 3. Supply & Exception Agent
Supliful already handles the deterministic fulfillment path.
Operator does not attempt to rebuild a supplier or order-routing system.
This agent focuses on operational anomalies such as:
- delayed fulfillment
- product unavailable
- order stuck in an unexpected state
- supplier-side exception
- repeated delays affecting multiple customers
- inventory / availability mismatch
- a product issue that requires customer communication
Example:
Supplier exception detected
↓
Find impacted Shopify orders
↓
Identify customers affected
↓
Estimate severity
↓
Customer Ops prepares communication
↓
Lifecycle Agent suppresses conflicting marketing if needed
↓
Operator summarizes business impact
↓
Founder sees one decision if required
This is where multi-agent coordination is actually valuable: one operational exception can affect customers, marketing, and founder priorities at the same time.
✉️ 4. Lifecycle Agent — Powered by Sequenzy
Operator does not rebuild an email marketing platform from scratch.
Sequenzy remains the execution engine for lifecycle email.
The Lifecycle Agent supplies the reasoning layer on top.
It can reason over:
- Shopify purchase history
- customer lifecycle state
- time since last order
- previous campaign engagement
- customer segments
- product purchased
- repeat-purchase window
- campaign results
Then use Sequenzy tools / API capabilities to perform bounded actions such as:
create or update subscriber
apply lifecycle segment
trigger sequence
prepare campaign
create A/B test
inspect campaign analytics
pause or adjust lifecycle workflow
Example: second-purchase lifecycle
Customer bought Coorg Sunrise
14 days ago
First order
No second purchase yet
Lifecycle Agent determines that the customer belongs in the first-purchase-to-repeat journey and triggers the correct Sequenzy workflow.
Example: win-back campaign
Operator discovers:
137 customers
last purchase: 28–40 days ago
no repeat order
Lifecycle Agent can prepare:
Campaign: Replenishment / Win-back
Segment: 28–40 day non-repeat customers
Subject A: Your next cup is waiting
Subject B: Running low?
Offer policy: configured by founder
Primary metric: repeat purchase rate
Secondary metric: revenue per recipient
It can then monitor the experiment and recommend whether A or B should become the default.
📊 5. Business Analyst Agent
The Business Analyst turns raw company activity into founder-level decisions.
It can inspect:
- Shopify revenue and orders
- support / refund trends
- fulfillment exceptions
- lifecycle campaign performance
- repeat purchase behavior
- current unresolved operational issues
It does not simply say:
Revenue fell 18%.
It helps Operator investigate why.
Example:
Revenue down 18%
↓
Traffic stable
↓
Checkout conversion down
↓
Support mentions shipping cost increased
↓
No major fulfillment outage
↓
Hypothesis: shipping friction is suppressing conversion
Operator can then prepare one bounded decision for the founder rather than dumping five dashboards on them.
☀️ The Morning Briefing
A scheduled EventBridge trigger can start the most important Operator workflow of the day.
Example output:
GOOD MORNING
Revenue yesterday: $1,842
Orders: 61
Repeat purchase rate: +6%
Handled automatically:
• 2 routine customer issues resolved
• 1 fulfillment exception tracked
• 34 eligible customers entered a replenishment lifecycle
Needs your decision:
1. Approve recovery offer for order #1831
2. Product availability issue affects 9 open orders
3. Win-back sequence B is outperforming A by 21% — make B permanent?
This is the product experience.
Operator reduces the founder's decision surface area.
🔄 How the Agents Interact
The agents are not peers all talking at once.
Operator remains the supervisor.
Trigger / Schedule
│
▼
Operator
│
classify problem / intent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Customer Ops Supply Exception Lifecycle
│ │ │
│ impacted orders │
│ │ │
└──────── evidence ┼────── evidence ───┘
▼
Business Analyst
│
recommendation + risk
▼
Policy Layer
/ \
/ \
safe autonomous founder approval
action │
\ /
\ /
▼
Verify result
│
▼
Persist outcome
Specialists return typed objects such as:
CustomerIssueAssessmentFulfillmentExceptionLifecycleRecommendationBusinessFindingProposedActionApprovalRequest
This gives the supervisor reliable handoff contracts and makes the system testable.
🏗️ Technical Architecture
┌─────────────────────────────────────────────────────────────────┐
│ BUSINESS SYSTEMS │
│ Shopify • Supliful signals • Sequenzy • Support / Email │
└──────────────────────────────┬──────────────────────────────────┘
│ webhooks / scheduled reads
▼
EventBridge + SQS
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ AGENTCORE RUNTIME │
│ OPERATOR — Strands Agent │
│ │
│ observe → delegate → investigate → act → verify → escalate │
└───────────┬───────────────┬───────────────┬─────────────────────┘
│ │ │
▼ ▼ ▼
Customer Ops Lifecycle Agent Supply Agent
│ │ │
└───────────────┼───────────────┘
▼
Business Analyst
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ TOOL LAYER │
│ Shopify API • Sequenzy API • Supplier adapters • Support tools │
│ typed inputs • permission scopes • validation • idempotency │
└──────────────────────────────┬──────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ POLICY ENGINE │
│ refund cap • coupon cap • send policy • approval requirement │
└──────────────────────────────┬──────────────────────────────────┘
│
┌─────────────┴─────────────┐
▼ ▼
Autonomous action Approval request
│ │
└─────────────┬─────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ STATE + MEMORY + OBSERVABILITY │
│ DynamoDB • AgentCore Memory • CloudWatch • audit history │
└─────────────────────────────────────────────────────────────────┘
🧠 Memory Model
Operator needs memory, but not every fact should become free-form agent memory.
The architecture separates three categories.
1. Structured business truth
Stored deterministically in business systems / DynamoDB:
order state
customer id
campaign id
refund amount
fulfillment state
run status
approval state
2. Current run state
run_id
trigger
specialists_called
evidence_refs
pending_action
risk_class
approval_status
error_state
3. Long-term operator preferences
AgentCore Memory can hold useful founder context such as:
Refunds under $25 may be resolved automatically.
Never discount the Reserve line by more than 10%.
Do not automatically change product pricing.
Prefer customer recovery over refund when shipment delay < 5 days.
Founder wants only high-priority issues in the morning briefing.
Memory personalizes the chief of staff without replacing structured source-of-truth data.
✉️ Why Sequenzy Instead of Rebuilding Email on SES
Operator deliberately uses Sequenzy for lifecycle marketing because that capability already exists.
The agent should reason about:
- who should receive a message
- which lifecycle should trigger
- what experiment should run
- whether a sequence should pause
- what the performance means
Sequenzy should continue to handle the campaign / sequence machinery.
Amazon SES can still be used where native email infrastructure makes sense — for example system notifications or founder alerts — but rebuilding full lifecycle email on top of SES is not the core hackathon problem.
The hackathon value is the Strands reasoning and orchestration layer, not duplicating an existing email platform.
🛡️ Human-in-the-Loop Policy
Operator classifies actions before execution.
READ ONLY
→ execute
LOW-RISK INTERNAL
→ execute + log
LOW-VALUE CUSTOMER ACTION
→ execute if policy permits
EXTERNAL / REVERSIBLE
→ execute only within configured bounds
STRATEGIC / FINANCIAL / SENSITIVE
→ require founder approval
Examples of approval-gated actions:
- large refund
- material customer compensation
- significant discount policy change
- lifecycle campaign with a new promotion
- supplier commitment
- sensitive outbound communication
An approval request contains:
- proposed action
- evidence
- recommendation
- impact
- policy / risk reason
- exact operation that will execute
The founder does not redo the investigation.
🔐 Security
The LLM never receives raw long-lived credentials.
The execution layer uses:
- AWS Secrets Manager
- scoped IAM roles
- capability-specific tool adapters
- read / write separation
- server-side schema validation
- action allowlists
- approval policies outside the model
- sanitization of untrusted customer text
Customer emails, support messages, and other external text are treated as data, never as tool instructions.
🔁 Reliability
Operator is designed for workflows that may span multiple services and fail halfway through.
The runtime uses:
- stable
run_id - durable SQS-backed work
- bounded retries
- exponential backoff
- tool timeouts
- explicit partial-failure state
- idempotency keys for side effects
- dead-letter handling
- result verification
Example:
If a recovery coupon is successfully created and the next step crashes, restarting the run must not create a second coupon.
👀 Observability
CloudWatch / AgentCore observability records operational metadata such as:
- trigger source
- run start/end
- specialist agents invoked
- tools selected
- tool latency
- tool success/failure
- evidence references
- risk class
- autonomous actions
- approval requests
- final result
The product records auditable operational evidence without exposing private hidden reasoning.
☕ Demo: Molten Coffee
Molten Coffee is the real business environment used to demonstrate Operator.
Existing systems
Shopify
│
├── normal order ───────► Supliful ───────► fulfillment
│
└── business events / exceptions ───────► Operator
Operator
│
├── Customer Ops
├── Supply / Exceptions
├── Business Analysis
└── Lifecycle Agent ─────► Sequenzy
Demo story
1. EventBridge triggers the morning business scan.
2. Operator loads overnight Shopify activity.
3. Customer Ops finds a delayed order with repeated customer contact.
4. Supply Agent confirms the fulfillment exception.
5. Customer Ops prepares a recovery action within policy.
6. Lifecycle Agent identifies a repeat-purchase segment in Sequenzy.
7. Business Analyst summarizes revenue and operational changes.
8. Two routine actions execute automatically.
9. Three high-value decisions enter the founder queue.
10. Founder approves one action.
11. Operator executes it, verifies the result, and records the outcome.
The demo should end with the founder seeing less work, not more AI output.
🧩 AWS Technology Stack
- Strands Agents SDK — supervisor + specialist agent implementation
- Amazon Bedrock — model access
- Amazon Bedrock AgentCore Runtime — managed agent execution
- AgentCore Memory — durable operator preferences and long-term context where appropriate
- Amazon EventBridge — scheduled business workflows
- Amazon SQS — durable asynchronous jobs and retries
- Amazon DynamoDB — structured run state, approvals, and operational records
- AWS Secrets Manager — credential storage
- Amazon CloudWatch — logging, metrics, and runtime observability
- Shopify Admin API / webhooks — commerce and customer context
- Sequenzy API / agent tools — lifecycle campaigns, sequences, subscribers, experiments, analytics
- Supliful / fulfillment signals — supplier exception context where available
- Amazon SES — optional founder / system notifications, not the lifecycle marketing engine
- Python + Pydantic — typed tools and structured agent handoffs
🧪 Testing Strategy
Specialist tests
- delayed-order fixture routes to Customer Ops
- normal fulfilled order causes no unnecessary agent action
- dormant-customer fixture routes to Lifecycle Agent
- supply exception identifies the correct impacted orders
Policy tests
- refund above threshold cannot auto-execute
- discount above configured cap requires approval
- read-only investigation cannot trigger a write tool
Memory tests
- founder preference affects recommendations
- free-form memory cannot override current Shopify truth
Reliability tests
- duplicate SQS message
- Sequenzy temporarily unavailable
- Shopify read timeout
- partial fulfillment data
- customer text containing malicious instructions
- crash after a successful side effect
End-to-end test
A scheduled run invokes specialists, resolves at least one routine item, creates an approval request for a high-risk item, executes an approved action, and records the full outcome.
🌍 Why It Matters
Small companies rarely need an AI to replace the founder.
They need an AI to absorb the coordination tax around the founder.
Operator explores a professional-agent model where the business continues moving in the background, normal workflows remain deterministic, agents handle exceptions and context-heavy work, and the human appears only when judgment is genuinely valuable.
The founder remains in control. Their attention stops being the bottleneck.
🛠️ Current Build Status
Operator is being built specifically for the Agents for Humans Hackathon — Professional Agents track.
The page documents the target architecture while implementation is in progress. The final Strands implementation, AgentCore deployment, public repository, architecture image, live demo, demo video, screenshots, and measured test results will be attached as the build is completed.
Built With
- agentcore-memory
- amazon-bedrock
- amazon-bedrock-agentcore-runtime
- amazon-cloudwatch
- amazon-dynamodb
- amazon-eventbridge
- amazon-ses
- amazon-sqs
- aws-secrets-manager
- pydantic
- python
- sequenzy-api
- shopify-admin-api
- strands-agents-sdk
Log in or sign up for Devpost to join the conversation.