How Warren Stays in Touch Without Being Annoying

Financial planning apps have a retention problem. Users arrive with good intentions - they create a plan, set some goals, maybe enjoy the onboarding experience. Then life happens. The app goes silent. The user goes silent. Three months later, their plan is stale, their circumstances have changed, and the app has become another forgotten icon on their home screen.

The traditional solutions are predictable: scheduled email campaigns, generic push notifications, "It's been a while!" messages. These approaches share a common flaw - they're timer-based, not context-based. A notification that fires because 14 days have passed since the last login knows nothing about whether the user's situation has actually changed, whether their plan needs attention, or whether reaching out right now would be helpful or irritating.

We wanted something different. Not a notification scheduler, but a system that actually understands each user's financial situation, considers what's happening in the outside world, and reaches out only when it has something specific and useful to say. The key insight: most days, the right thing to do is nothing.

At the core of Warren's proactive engagement is a heartbeat - a daily AI agent run for every active user. The heartbeat doesn't just check whether a user has logged in recently. It reads their entire financial context: personal circumstances, financial plan, goals, current progress, the agent's own memory of past interactions, and the latest financial news and regulatory changes. Then it makes a decision: does this user benefit from hearing from me today?

Most days, the answer is no. That's the system working correctly.

When the heartbeat does decide to reach out, the message is specific and tied to the user's situation - not a generic nudge. The difference between "It's been a while - come check your plan!" and "ISA deadline in 3 weeks - you have £15k to allocate" is the difference between a notification system and a financial companion.

The heartbeat is the primary mechanism, but it's part of a broader agent system. The same architecture also processes conversation summaries after a chat or voice call, executes reminders that the agent previously scheduled for itself, and handles background tasks delegated by the chat interface. All of these share a single agent framework - the same memory layer, tools, compliance guardrails and so on - creating a coherent system the user perceives as "Warren".

When the heartbeat runs, it doesn't make API calls to fetch bits of user data on demand. Instead, we build an ephemeral workspace - a temporary directory of files that mirrors everything the agent needs to know about the user. This workspace is constructed fresh from the database at the start of every run and destroyed when the run completes.

The workspace is organised into three sections:

The User's Financial Life - a snapshot of the user's financial data on our platform. Their personal circumstances (age, employment, family situation etc), financial plan, goals and progression history. Context management here is key, with a signficant uplift in observed eval quality between a simple database JSON dump and a more curated approach that we take.

External Context - what's happening in the outside world that might affect this user. Financial news from the last seven days, regulatory changes, tax deadlines, market events. This is partly automated via scraping and data feeds, partly manually curated by our expert teams.

Warren's Memory - This is the agent's persistence layer across runs. It includes structured user-facing artefacts such as decisions made and reasoning. Additionally, we saw a performance uplift when adding a non-user-facing, unstructured layer of agent memory. eg. "Keep track of how the user likes to be talked to".

Why files instead of structured API calls? Because the agent is a general-purpose reasoner operating on diverse, evolving data. The agent needs to explore, search, and cross-reference before deciding - capabilities that map naturally to file navigation but awkwardly to predefined endpoints. The agent interacts with its workspace using file-system tools: read, edit, grep, find, jq. Much more efficient than an endless list of custom tools, and the invocation signature is widely present in the training data of all LLMs, allowing us to pick models without focusing on instruction following as the primary metric.

The workspace is ephemeral, constructed from the database with strict per-user separation at code-level, not LLM-level.

The heartbeat is built around a single guiding principle:

This is the hardest design decision to maintain, because every product instinct pushes the other way. More messages feel like more engagement. Silence feels like the system isn't working. But for a financial planning companion, trust is the product - and nothing erodes trust faster than irrelevant notifications.

The agent applies a simple value test: if the user would not obviously benefit from reading this message right now, don't send it. A vague nudge, a generic check-in, or a "just saying hi" doesn't pass. Value means a specific, timely insight tied to their plan, their finances, or a real-world event that affects them.

Every run ends with a structured decision - enforced by a defined schema - that produces one of two outcomes: silent_skip (deciding to stay quiet) or send_message (reaching out with something specific).

When the agent does send a message, precision matters:

To further prevent the risk of spam, we implement an additional harness around processing the LLM's decisions. One technique, for example, is to simply treat priority level low the same as silent_skip.

An agent without memory treats every run as its first interaction. Warren remembers, building up both a running log of all runs and decisions, and an internal continuously updating key information document.

Self-scheduling takes this further. If a user mentions they're expecting a salary review in March, the agent can create a reminder for mid-March: "User mentioned salary review - check if their plan needs updating."

Notice the schedule is not to send a message in mid-March, but to trigger execution of itself. When March arrives, the scheduled run picks up the reminder, checks whether it's still relevant, and acts accordingly. If the user has already updated their plan, the reminder gets a Silent Skip. It's the difference between "send a notification every 14 days" and "this user mentioned a house purchase in Q3 - follow up when mortgage rates change."

Rather than building separate systems for each type of proactive engagement, we designed a single agent architecture that adapts through roles. The heartbeat is the primary role, but the same framework also runs:

The agent's core loop is identical across roles: load workspace, call tools, produce structured output. This means improvements to reasoning, tool handling, or compliance checking benefit all roles simultaneously. And critically, roles share context - a heartbeat run can read the memory notes left by a conversation summary, creating continuity across different types of interaction.

To make sure the agent keeps behaving correctly as we iterate, we test it with a combination of deterministic assertions, post-run database checks, and an LLM judge that evaluates behavioural quality against a rubric - each test run snapshots and restores user state, so tests stay repeatable.

Building a proactive system has taught us things that building a reactive chatbot didn't:

Silence is a feature. The most important metric isn't how many messages we send - it's how often users find those messages useful. A system that sends one perfectly-timed, contextually-relevant message per month is more valuable than one that sends weekly generic check-ins.

Memory changes everything. An agent without memory treats every run as its first interaction. An agent with memory builds a relationship - it knows what it's already said, what worked, what the user cares about. This is the difference between a notification system and a companion.

Everything is moving to CLI. A savvy reader will notice that our system is obviously inspired by OpenClaw. Building and tearing down a file-based workspace for every run might seem like overkills as there is a lot of added complexity and latency. But the payoff is in the agent intelligence, extendibility, auditablity, and, ultimately, customer outcomes.

We started with a specific problem: users create financial plans and then disengage. Traditional notification systems respond with timer-based messages that know nothing about the user's actual situation.

We built a daily heartbeat - an AI agent that reads each user's full financial context, checks the outside world for relevant events, consults its own memory of past interactions, and makes a decision: does this user benefit from hearing from me today? Most days, the answer is no. When it is yes, the message is specific, timely, and compliant.

The broader lesson: for a product that positions itself as a trusted financial companion, the quality of proactive engagement matters more than the quantity. An AI system that knows when to stay quiet is more valuable than one that always has something to say.