Pod AI Workbench
An AI operations workbench embedded in AfterShip Feed — converting fragmented multi-product signals into a prioritised daily decision list. Merchants handle 3–7 AI-surfaced decisions each morning instead of navigating dashboards across five products.
Context
AfterShip's multi-product merchants — running Tracking, Returns, Email, Affiliates, and Personalization simultaneously — face a compounding attention problem. Every product surface shouts for attention. No surface tells them what to prioritise. No surface connects the signals across products into a decision.
Pod is the answer to that gap: an AI workbench that watches your business across all AfterShip products and brings you the decisions worth making today — with evidence, context, and a recommended action already prepared.
Positioning
Organised around decisions, not conversations.
Every major productivity tool organises work around a different object. Slack organises around conversations. Gmail around messages. Linear around issues. ChatGPT around prompts. Pod organises work around AI-detected business decisions — the ones that already have evidence, a recommendation, and a clear action attached.
This single positioning choice determines all subsequent design decisions: Pod doesn't do chat, doesn't do inbox, doesn't do issue tracking. It does "what the AI has already assessed and determined is worth your decision today."
| Product | Organises work around |
|---|---|
| Slack | Conversations |
| Gmail | Messages |
| Linear | Issues |
| ChatGPT / Claude | Prompts and outputs |
| Pod | AI-detected business decisions |
Product form
Three core pages and a settings modal.
Pod has four product surfaces, deliberately separated by usage frequency. The hierarchy of the sidebar reflects that hierarchy directly — Today's Actions always sits first.
| Surface | Mental model | Layout | Core components |
|---|---|---|---|
| Today's Actions | Decision inbox | 3-column (sidebar 240 + conv list 360 + detail flex + drawer 360) | Pod Briefing · Conv list · Recommendation Card · View Data Drawer |
| Spotlight | Watch boards | 2-column (sidebar 240 + board grid) | Watch Boards · V3 decision-action card |
| Agents | AI team management | 2-column (sidebar 240 + agent card grid) | Agent card · 3-tier permission display · Recent runs |
| Settings | Relationship archive | 800×600 modal (not a page) | About Pod · Memory · Voice & tone · Automation · Connections |
Settings becoming a modal — not a fourth sidebar tab — was a deliberate decision. When it was a tab, its visual weight implied parity with the three core surfaces. Moving it to a modal makes clear that it's configuration, not navigation. Closing it returns the merchant to exactly where they were.
Usage rhythm
Designed around how merchants actually use it.
The entry hierarchy in the sidebar mirrors the intended usage cadence. This isn't decorative — it's the core operating model of the product. Each surface is visited at a different frequency, and the visual weight of each should match that frequency.
Daily
Today's Actions
Handle 3–7 decisions each morning. Like processing email, but every item has a recommendation attached.
Weekly
Spotlight
Check Watch Boards once. See which product clusters have new opportunities or risks.
Monthly
Agents
Review each Agent's recent runs. Adjust permission boundaries if the business has shifted.
Rarely
Settings
Initial setup and occasional reconfiguration only. Not a daily destination.
Interaction model
What a complete decision looks like end to end.
Each decision in Today's Actions is a full package: signal → reasoning → recommendation → evidence → action. The merchant never has to leave the surface to understand why something is happening. Below is a complete example from detection to execution.
Background — Pod runs automatically
Inventory Guardian Agent checks every 6 hours → LED Lamp Pro: 8 units remaining, +18% sales acceleration, 10-day supplier lead time → Calculates: stockout in ~3 days · ~$3,400 GMV at risk → Triggers a Signal
Foreground — merchant sees in Today's Actions
Conv list: "LED Lamp Pro may stock out in 3 days" [Needs approval] → Detail: POD RECOMMENDS — "Restock 500 units from Victor Lee…" → Expected impact: "Prevent stockout and protect ~$3,400 GMV" → CTA: Contact supplier (one action, one click) If merchant opens View Data Drawer: → 3 signal chips: 3 days · +18% · 10 days → 4 data source chips: Shopify · TTS · Sales · Action history → Confidence: High · 14 / 14 days of data · sparkline → Detected by: Inventory Guardian · Recent runs timeline
Key design decisions
Six trade-offs, surfaced deliberately.
Design reviews tend to defend decisions after the fact. This section does the opposite — it names the trade-offs upfront so reviewers can challenge them on their actual merits.
| Decision | What we chose | What we gave up | How we compensated |
|---|---|---|---|
| Today's Actions UX model | Decision inbox (like email) | Free-form query and exploration | Conversation thread under each recommendation for follow-up questions |
| Spotlight model | Persistent Watch Boards (monitoring) | On-demand search | Each board is a pre-set collection Pod monitors continuously |
| CTA language | Specific verbs only ("Contact supplier", "Apply optimisation") | Lower copy-writing speed | Enforced as a design principle — generic verbs are blocked |
| State B visual scope | Full-screen — global 56px sidebar hidden | Can't jump directly to other AfterShip products | "Switch back to Feed" always visible in Pod sidebar, one click |
| Pod narrative voice | First-person ("I'm watching 6 products") | Feels less formal in some business contexts | Data and impact figures always use objective Inter; first-person confined to status and briefing copy |
| Settings as modal | Overlay, not a page | Less room for complex settings flows | Default landing is About Pod (relationship archive), not a config form |
Design critique · Today's Actions
"It's a hybrid of email and chat — we need chat to let merchants provide additional context." The inbox model is right for prioritised decisions, but chat isn't eliminated — it's subordinated. Merchants need a way to interrogate a recommendation before acting on it. The conversation thread under each card serves this role, but needs to stay clearly secondary to the decision itself, not visually compete with the Recommendation Card.
Trust architecture
From observer to collaborator — four stages.
The core design challenge isn't UI — it's trust. A merchant won't let an AI act on their behalf until they believe it won't overstep. The product needs to earn that trust progressively, not demand it upfront.
Day 1 · Observer
"I'll see what it says."
Every action requires approval. Merchant manually evaluates each Pod recommendation before anything happens.
Week 2 · Evaluator
"The logic makes sense, but show me the data."
View Data Drawer provides the full evidence chain: signal chips, data sources, confidence rating, detecting Agent, recent runs timeline.
Month 1 · Delegator
"Handle the small things automatically."
Settings → Automation lets merchants set auto-approval rules. e.g. "Auto-approve decisions under $10K."
Month 3+ · Collaborator
"We manage this store together."
About Pod relationship archive surfaces shared history: Conversations 142 · Cards handled 87 · GMV impact $11.2K.
Design critique · Agents trust display
"The current design doesn't clearly differentiate these three cases, and doesn't build that mental model for the user. The only mitigation right now is requiring approval for every action — which helps, but doesn't fully solve the trust problem."
The three-tier permission display (Can do automatically / Needs approval / Cannot do) is the right conceptual framework, but it needs visual weight to be legible — not just a text list. MVP scopes all actions to "Needs approval" as a safe default, which partially mitigates the trust gap. The full differentiated display is scheduled for Phase 3. The Agents section needs to make the tier distinctions immediately scannable, not require reading.
Design validation
Five questions a merchant asks in two seconds.
Any Recommendation Card in Today's Actions must pass this test before it ships. If any question goes unanswered by the UI, the design is incomplete.
| # | Merchant's question | Where the answer lives |
|---|---|---|
| Q1 | What is this task? | Detail title — immediately visible |
| Q2 | Why does it matter right now? | Decision status badge + "Why now" in Recommendation |
| Q3 | What does Pod suggest? | POD RECOMMENDS — 17px Source Serif, dominant visual weight |
| Q4 | What can I click right now? | 4 specific CTAs — concrete verb + concrete object, no generic labels |
| Q5 | What happens when I do? | Expected impact paragraph — states business outcome in numbers |
Any of these questions going unanswered is a design failure, not a content gap.
Phased roadmap
Four phases from alpha to GA.
| Phase | Timeline | Scope | Goal |
|---|---|---|---|
| Phase 1 · Decision Inbox MVP | 2026 Q2 | Today's Actions full loop · 4 signal types · Recommendation Card · View Data Drawer · Pod Briefing · Status badges | Complete decision flow works end to end |
| Phase 2 · Spotlight Watch Boards | 2026 Q2 | Watch Boards grid · V3 decision-action card · 4 default boards · Pod Monitoring Summary | Merchant sees what Pod is watching |
| Phase 3 · Agents Visibility | 2026 Q3 | Agent card grid · 6 built-in Agents · 3-tier permission display · Recent runs timeline · Automation settings | Merchant trusts who is working in the background |
| Phase 4 · Trust & Personalisation | 2026 Q4 | About Pod relationship archive · Memory system · Action Draft editor · Weekly Pod Digest email | Merchant upgrades from user to collaborator |
Three categories are permanently out of scope: Workflow Builder (contradicts Pod's AI-first positioning), AI Marketplace (outside AfterShip's data security boundary), and general-purpose chat (collapses the decision-inbox mental model).
Design principles
Six lines that hold all design decisions accountable.
| Principle | Test |
|---|---|
| P1 · Decisions first | Does this help the merchant decide the next best action faster? Keep if yes. Remove if it only displays state. |
| P2 · Pod is a colleague, not a tool | Pod uses first person. Pod comes to the merchant. Pod remembers. |
| P3 · Transparent beats clever | Every recommendation must be interrogatable. View Data Drawer is always one click away — never buried. |
| P4 · Specific beats generic | CTAs must name a concrete verb + object. Badges must name a concrete next step. Numbers must carry business impact. |
| P5 · Consistent beats novel | Before adding a new pattern, ask: does the existing pattern fail here? If not, reuse it. |
| P6 · Don't interrupt the main task | View Data Drawer is not a modal. Settings closes back to the same state. Reply thread doesn't compress the Recommendation Card. |