Principal Product Designer, leading end-to-end design. My contribution defined the underlying thesis, led four design iterations, worked with 5 design partners in weekly sessions, prototyped every iteration with Claude Code, and partnered with eng on POCs for agent execution.
Most AI products today are optimized for responses, not outcomes. They rely on chat, expose too much underlying structure, and require constant user direction. As models become more capable, and user expectations increase with each breakthrough, users don’t want to manage prompts or workflows, they want to review outcomes.
The challenge is not capability, but behavior. If an AI system can take action over time, what should it do without being asked? When should it surface decisions? How do you make its behavior understandable enough to trust, without overwhelming the user with internal complexity?
I designed an Assistant that operates as a system, not an interface. Users interact through intent, while the Assistant plans, executes, and adapts in the background. Instead of exposing agents or tools, the system absorbs that complexity and surfaces only what matters: actions taken, decisions made, context that informed those decisions, and items that require review.
The result is a shift from prompting to collaborating. The Assistant doesn’t just respond – it moves work forward. It identifies opportunities, executes tasks, and brings the user in at the right moments, with enough context to understand and act, without needing to manage the system itself.
A system that operates before you arrive
The Assistant runs continuously - identifying opportunities, executing work, and surfacing what matters when you return.
Core beliefs
Users want to move from intent to outcome. Over time, the log of events powering execution requires less review.
Users should interact with intent, not workflows
The Assistant is the primary interface to the system
Systems should act, not wait to be prompted
Autonomy should be graduated and interruptible
Complexity should be absorbed, not exposed
Systems should be legible without full transparency
Validation strategy
The Autonomous Coworker design partner program runs a staged engagement: target customers commit to giving feedback on iterative designs and participating in the alpha
Cadence
A tight loop that turned weeks of mock-and-review into days of build-and-test.
Sessions
Multiple per week over Zoom
Feedback
Continuous in Slack channel
Synthesis
End-of-week with research
Prototype updates
Build for next week
↻ Loops weekly
Explore the prototype, built with Claude Code
I built a working prototype with Claude Code in 4 days, deploying new versions weekly. This let me test the behavior of the system, not just its appearance, and move fast while incorporating feedback.
Three decisions that shaped the system
"Why should I trust the Assistant?"
Early versions showed finished work but reasoning was buried. Better outputs built trust over time, but users needed to feel confident before granting autonomy, not after.
The change: Context became inline and on-demand. Every message shows the "why" in hover states and expandable panels. Selective, digestible transparency accessible at the point of action.
"I want to manage outcomes with confidence."
Early versions prioritized tasks and to-dos, but leads were scattered with no source of truth. Every participant in our first two research waves pushed back - they wanted to see who the meetings were booked with.
The change: Campaigns - a singular organized artifact that contains data sources, prioritized leads, and where they are in their journey.
"How does this connect to my bottom line?"
Users understood what the system was doing, but not what it meant for their performance. The tension was subtle: they didn't want to manage goals, they wanted the Assistant to know what to work against.
The change: The surface becomes goal-oriented in the background. Every action surfaces expected impact in the user's existing metrics. The right rail tracks the full funnel, visualizing the living system and how the work ladders to an underlying goal.
An evolution: The system acts and surfaces what matters
From activity monitoring to coworker: The Assistant runs continuously, identifying opportunities and executing work. Instead of requiring prompts, it presents a prioritized view of what changed, what was done, and what needs attention. Home becomes a communication surface with prioritized messages from the Assistant, evoking how a user might start a day in office with a coworker.
The Assistant runs continuously, identifying opportunities and executing work. Instead of requiring prompts, it presents a prioritized view of what changed, what was done, and what needs attention. Home becomes a communication surface with prioritized messages from the Assistant, evoking how a user might start a day in office with a coworker.
V1
Activity-focused, monitoring system. Heavily focused on Assistant activity oriented around a system goal. This made the surface feel like activity monitoring and overwhelmed users without providing enough insights on why the Assistant was taking specific actions.
V2
Goals as user-facing objects. Goals became first-class, each maintained by a project with its own Assistant instance. The system could orient around multiple goals at once - but users now had to manage the goals on top of managing the work.
V3
Goals move into the system, Assistant still separate. Goals shifted into the underlying intelligence rather than the user surface. An AI Inbox emerged as the hub for Assistant work. Capability improved, but the Assistant still felt like an add-on alongside the rest of the product.
V4
The Assistant becomes the surface. The earlier versions still read as task lists with AI bolted on. V4 collapses the distinction: the Assistant is the surface. Work, context, and outcomes flow through one cohesive system that behaves like a coworker, not a tool.
Execution, powered by context and knowledge
Trust in autonomous systems comes down to two questions: why should I let it act on my behalf, and how do I know it won't make things up? The Assistant answers both by retrieving from three layers of grounded knowledge, synthesizing what's known and observed.
Layer 3User patterns
User provided data and preferences plus user activity observed across Apollo and connected tools.
Layer 2Team and account level context
Admin playbooks, ICP rules, brand voice, website data, CRM, alongside learned patterns observed across reps that consistently produce outcomes.
Layer 1Apollo data
Apollo's decade of structured sales data across verified contact and account entities, intent signals, and firmographics.
Each item reflects work the system has already progressed. Here, a fully prepared, hyper-personalized outreach campaign. The user reviews and intervenes at the right moment, rather than building from scratch.
Context is embedded directly into the interface - signals, reasoning, and supporting data are surfaced inline, allowing users to quickly understand why the system acted without exposing the full underlying complexity
From prompting to delegation
As the system became more capable, the interaction model shifted from issuing commands to handing off work. Users define intent, and the system determines how to execute.
Users define intent and hand off work, allowing the system to plan, execute, and return at the right moments.
The user hands off a goal - monitoring and improving sequences - while the system operates in the background. It analyzes performance, proposes changes, and brings the user in only when input or approval is needed
