From Signal Detection to a System of Intelligent Action
Echo proved that an AI agent could detect what was happening in a customer account and recommend intelligent responses. CSMs went from spending 1.6 days a week in Hook to 3.3, and weekly active users rose from 71% to 89% in a year.
This case study is about what came next: a system of action that turned agent recommendations into the primary CSM workflow – a centralised task list bringing together actions from agents, automations, and manual entries, with agents that work continuously towards defined goals rather than reacting to individual signals. Activator, the first goal-oriented agent, was built within this system and focused on onboarding.
The problem – agents without a system
Echo's playbook model worked. For each signal detected, it generated three suggested actions – a focused, bounded response that CSMs could act on immediately.
But Echo had two structural limitations. First, no goal model: Echo reacted to signals, proposed a response, and was done. A CSM completing Echo's actions was clearing a reaction queue, not progressing towards a customer outcome. Second, no central home: Echo's actions lived on the account page, meaning working through agent-generated tasks required navigating account by account. Everything was distributed rather than surfaced in one place.
The answer was a centralised task list and agents that worked continuously towards a defined goal. Onboarding was the right starting point – every customer goes through it from a common baseline towards a common set of goals. That predictability made it the right place to design the first goal-oriented agent: Activator.
The system of action
I defined a framework mapping how the concepts we had – and would need – related to each other:
Agent objective – a collection of goals an agent works towards autonomously.
Goal – something measurable within a timeframe. The unit of success.
Plan – a series of actions required to achieve a goal. Adjusts dynamically.
Action – something an agent or human can execute. Carries content: a drafted email, a meeting agenda, a call script.
Agent objective and Plan are the two concepts doing the real work. An objective is a standing goal; a plan adjusts as context changes, so the agent is continually re-evaluating what to do next. That mechanism – observe, plan, act, replan – is what the industry now calls an agentic loop. Activator was the first Hook agent built around it.
The framework was also the conceptual backbone for a broader set of planned features: a task management and goals layer, and a new CSM homepage built around action rather than insight.
Designing the agents
Before designing the configuration experience, I defined the prompt architecture – the structure governing how any Hook agent is built and run, combining contextual information (business context, metrics, products) with agent-specific prompts and deactivation criteria that define what success looks like.
An early idea was to have agents build forward-looking plans – a sequence of future actions with a full audit trail. Too speculative. The approach we landed on instead: ground agents entirely in current context, write that context to a memory table, and reschedule the agent to run again in the future. When it picks up, it reads those memories before deciding what to do next. The plan emerges from accumulated context rather than upfront prediction – a conclusion reached through designing and building in tandem, not at a whiteboard.
For configuration, I started with a comprehensive vision: a full UI for adding resources, MCP tools, and guardrails, with a sandbox to test agent behaviour before going live. Our first release deliberately simplified this to a single text field – giving customers an open canvas, removing rigid constraints so we could learn how they'd actually use them. Our instinct proved right. Customers built agents we hadn't anticipated, across different triggers, objectives, and output types. Several became productised agent types.
The design pivot – from list to grouped actions
The Actions page was the centralising surface – the single place where everything requiring a CSM's attention would live. Getting that right meant solving a problem that only became visible in design: when an agent suggests multiple actions at once, a flat list makes them look unrelated. Each action appears as an independent item with no indication it was generated alongside the others in response to the same situation.
Working through that problem surfaced a concept that hadn't been in the original framework: origin – where an action came from. Once we had a name for the thing that connected a set of actions to their source, the interface question resolved itself. Don't show users a list of tasks – show them a set of situations, each with a plan for how to respond.
Each group represented either a situation an agent had reacted to, or the agent's current view of its progress towards a goal – reviewing context, assessing where things stand, and generating the next set of actions from that. Either way, context established once at the group level. The CSM could read it, understand what the agent was recommending and why, and move through the actions without rebuilding mental model at each step.
A flat list is a to-do list. A set of grouped, contextualised action plans is a briefing – here's what's happening across your accounts, here's what we recommend, here's the content to do it with.
Human-in-the-loop – trust as a design principle
The Actions page was the deliberate middle phase of a longer progression toward full agent autonomy. You can't release autonomy without trust, and trust has to be earned incrementally in production.
Human-in-the-loop was the mechanism: CSMs review suggested actions, edit drafts, decide what to send. Two purposes simultaneously – efficiency gains today, and the data to evaluate whether agents are ready to run unsupervised. To understand what reporting metrics actually mattered, I built Grafana dashboards covering agent performance, team productivity, and overall system health – validating the right signals before committing to a product surface.
The decision to grant autonomy sits with CS leaders, not individual CSMs. The threshold we heard consistently: around 80% agreement with agent suggestions. Reporting is the gate between human-in-the-loop and full autonomy.
We're currently designing the fully automated phase, shaped directly by what we learned: what customers trusted, where they pushed back, and what evidence they needed before letting go.
