Ai

For most of design’s history, the job has been to shape what’s visible. We worked with screens and flows, defined by best practices in visual hierarchy and gestalt principles. Now that experiences are increasingly powered by AI, the most consequential design decisions live in the substrate beneath the canvas: in how a system reasons, what values it expresses, what judgements it makes when the rules don’t quite cover the situation. As Suff Syed puts it, designers who stay at the surface risk being relegated to decorating the output of systems they never helped shape.

Why good AI guidance in wealth management starts with the problem, not the model A year ago, the fastest way to look innovative in wealth management was to bolt a chatbot about market commentary onto your product and call it AI. The market obliged. Tools were built, interest was assumed, and a strange focus formed around using AI to predict the market, reading sentiment and signals to drive transactions. The “AI model” was the product, and whoever had the most sophisticated one would win. We don’t believe that. And the reality only underscored the point. When capability is turned into a commodity and while the industry is still working out what makes commercial sense, the thing that sets you apart and stays consistent is the philosophy you encode into it. The specific area we chose to focus on is helping a real person define a goal they can realistically fund, and understand more intuitively how to best use our platform, not producing more data for someone to process. As Morgan Housel puts it, the soft skills of money matter more than the technical side. A model that answers market questions well but doesn’t encourage good behaviour is more informational bloat in a domain that demands a fiduciary.

At Endowus, hundreds of Sentry notifications flow daily into dedicated Slack alert channels. These alerts are essential for reliability and incident response, but keeping up with the volume is a different challenge altogether. We’ve written about our Sentry & Slack alerting setup in a previous post: Solving the Shared Ownership Alerting Challenge. Our initial setup worked well, but as alert volumes grew, the strain started to show. During a particularly busy period of releases and activity, working closely with our engineering teams as a Tech Program Manager, I could see how much time and attention was being diverted from product development into manually reviewing alerts. Useful signals were present — recurring errors, gradual spikes, subtle correlations — but extracting them required sustained focus across multiple Slack channels and time windows. Although I’m not a developer, I wanted to help the team solve this. Using AI-assisted development tools, I built an initial working prototype myself, iterating on data extraction, formatting and analysis logic. That first version made the concept tangible: structured interpretation could reduce review effort without disrupting existing monitoring workflows. Building the prototype also sharpened the problem definition. The alerts themselves were not broken: they were working exactly as intended. What was missing was a structured way to interpret them at scale.