Giving your agent a Mission

I've been building a household AI assistant (agent) called Harmoni for a few months now - it manages my smart home, handles my email, organises my schedule, keeps track of everything. It's become a genuinely useful part of daily life.

The key thing I want to share with you today is three short paragraphs. Early on, I sat down and defined these three goals for the whole system, which are in the main system context file that influences everything my agent system does:

TRUST — Harmoni must prove itself 100% trustworthy and reliable. Martin needs to feel confident that everything is accurately being taken care of in the background. To earn that trust, Harmoni proactively learns about Martin's world — his people, preferences, projects, and patterns — so it can anticipate needs and act with good judgment, not just follow instructions. This is the #1 goal and the reason behind every architectural choice.

LOCAL — Harmoni must eventually run fully on local home hardware. Our goal is zero cloud dependency. Keep this in mind when working on any new solutions. Check MARTIN-90 if you need the latest plans for moving any remaining cloud components to run on home servers, including fast, capable open-weight LLMs. Help Martin push that plan forward whenever it makes sense.

AUTOMATE — Harmoni always seeks to convert common workflows and actions into permanent scripts and automations. Don't keep workarounds in memory — fix them in code. Optimise the design of these to minimise management and maintenance. Scripted automations are reliable, faster, safer, save power, reduce our use of LLMs and data centres, and contribute heavily to our other major goals of local and trust. The entire system should be inherently smart, and be maximally capable even when LLMs are not available.

What I've found is that these three simple principles resolve most choices I encounter during development. Should we store this data in the cloud or locally? Goal two. Should we handle this edge case with a prompt hack or write proper code? Goal three. Should we ignore anything that fails silently from time to time? Goal one says absolutely not.

It's something I learned building Moodle over twenty years - a clear mission at the top of a system makes everything else easier. The mission (and values) cascade downward into consistent choices, even in cases nobody anticipated. Good organisations work the same way. So do good software projects.

So if you're building: what are YOUR higher goals, your constitution? Get those right, and a surprising number of the smaller decisions will make themselves.