Wingman

A proactive AI assistant has an awkward problem: if it works properly, it lives where you already are rather than in an app you remember to open. Wingman is a chief of staff that operates inside WhatsApp, briefing you in the morning, triaging email, watching bills and deliveries and travel, and remembering the commitments you made to people. The conversation is the product.

That leaves a question the conversation cannot answer on its own. If an agent is going to act on your behalf, you need somewhere to see what it knows, decide how much it may do without asking, and check what it has already done. A chat thread is a poor place to audit a system, and a poor place to change its settings.

The design problem is that the app is deliberately not where the work happens. Almost every pattern available for a productivity product assumes the app is the destination: dashboards to live in, inboxes to clear, streaks to maintain. Wingman inverts that. If a user is in the app for long, something has gone wrong in the channel that matters. So the app had to be genuinely useful and quick to leave, which rules out most engagement conventions and offers few precedents to borrow.

Underneath that sits a trust problem, and it is the harder one. An assistant that only reports is safe and close to useless. An assistant that acts is useful and frightening. The gap between those is not closed by a settings page with a few toggles, because the real questions a user has are specific and situational: what does it know about me, where did that come from, what is it about to do, what has it already done in my name, and how do I stop it. Each of those needs a surface, and none of them is a preference.

The app is organised as five tabs over a detail layer. Home, Calendar, Email, Tasks and More are siblings; everything else, the module screens for bills, deliveries, travel, people, health, business and news, plus notifications, profile and all settings, slides in over a tab and carries its own back bar. That split keeps the everyday surface shallow and lets the depth exist without cluttering it.

The answer to the trust problem is a single object, the approval card, and the decision that it is the only surface in the product that acts. Every action anywhere in the app, an email reply, a bill renewal, a travel change, a follow-up with a person, resolves to the same card. One object means one mental model: the user learns once what it means for Wingman to ask permission, and that knowledge holds everywhere. Approvals are logged, waiting items first and decided items after, so a decision is auditable after the fact rather than vanishing into a thread.

Designing the control surface for an agent is a different discipline from designing an app, and most of the available patterns actively mislead. The instinct to make a product sticky is wrong when the product's success means the user is somewhere else. Naming that inversion at the start, and writing it into the design direction as a stance rather than leaving it as an intuition, is what kept it from being eroded one reasonable-seeming addition at a time.

Trust turned out to be an information architecture problem rather than a copy problem. It was tempting to think reassurance comes from tone, from explaining carefully what the agent will and will not do. It does not. It comes from structure: one predictable object that asks permission, a log that survives the decision, memory the user can read and delete, and a dial rather than a switch. Every one of those is a surface someone has to design, and none of them is solved by wording.