// context_portfolio.md

Agent Context

Personal context portfolio: structured data about who I am, how I work, and what I care about. Designed for both humans and AI agents.

// rest_api

AI agents and MCP clients can access this context programmatically:

GET/api/context// List all context files
GET/api/context/identity// Get a specific file
GET/.well-known/ai-context.json// Agent discovery

// mcp_server

The MCP server exposes my full context portfolio to any MCP-compatible client. Any agent can call get_full_context and understand who I am before writing a single line.

tools

list_context_files// List all files with titles and descriptions
search_context// Full-text search across all context files
get_full_context// Load entire portfolio as one document

resources

context://adam-stacey/{filename}// Individual context file

setup

Works with any MCP-compatible client: Claude Code, Claude Desktop, Cursor, Windsurf, Cline, Continue, and others.

// Claude Code (auto-loaded from .mcp.json in repo root)

{
  "mcpServers": {
    "adam-stacey-context": {
      "command": "node",
      "args": ["${PROJECT_ROOT}/mcp/build/index.js"]
    }
  }
}

// Claude Desktop (add to claude_desktop_config.json)

{
  "mcpServers": {
    "adam-stacey-context": {
      "command": "node",
      "args": ["/path/to/ad-nav/mcp/build/index.js"]
    }
  }
}

// Build first: cd mcp && npm install && npm run build

Communication Style

communication-style.md

raw

How Adam writes, speaks, gives feedback, and expects to be communicated with — plus guardrails for any AI agent acting on his behalf.

# Communication Style ## The One-Line Version **Match the audience, back opinions with data, land the message in three points, and be a human about it.** ## Tone by Audience My style shifts deliberately depending on who I'm talking to: - **Exec / senior stakeholders** — concise, formal, polite. Always leads with the "so what". Bullet points preferred, and I try hard not to use more than three. Zero waffle. - **Peers** — friendly and informal. I use "mate" more than I probably should. Emojis are fine. Humour is fine. - **Direct reports** — warm, conversational, empathetic. Prose rather than bullets most of the time. Bullets when I'm trying to land a specific point or drive an action. - **Friends and personal** — full humour, full personality, no filter. ## Openers and Sign-offs - **Open with warmth** — "Hi [name]" or "Hey", almost always followed by asking how they are. It's genuine, not performative. - **Fridays** — "Happy Friday" goes on basically everything. It's become a tell. - **Email sign-off** — "Many thanks, Adam" - **Slack sign-off** — usually nothing, sometimes "thanks". No ceremony. ## Channel Rules Roughly how I decide where something goes: 1. **Default to Slack** for most things — quick, informal, lightweight 2. **Follow up on email** when something needs to be *for the record* — formal decisions, stakeholder commitments, anything I'll want to point back to later. Email is the audit trail. 3. **Call or meet in person** when Slack and email aren't enough — when tone matters, when it's sensitive, or when we need to actually think together rather than exchange messages Slack gets things moving. Email locks them in. Meetings unblock the hard stuff. ## Signature Moves Things I do consistently enough that they're basically part of my style: - **"Three points"** — if I can't condense something to three key points, I haven't thought about it hard enough. Three is the landing zone for getting buy-in or driving action. - **Opinion backed by data** — I'm happy to have a strong opinion, but I want to be able to point at the evidence behind it. "Let's look at the data" is a recurring phrase. - **Stupid questions as a superpower** — I'll happily ask the obvious question nobody else is asking. "Why are we doing it this way?" is a genuine enquiry, not a challenge. Context matters, but context isn't permission to stop questioning. - **Challenging the status quo** — by default. If we can't explain why something works the way it does, that's a signal, not a defence. - **Pragmatic over clever** — if a simpler solution does the job, that's the right solution. (See Partner AI Mapping — I picked agents over a trained model because it was simpler to maintain, not more impressive.) ## Things I Don't Do - **Cheesy corporate waffle** — I've been guilty of it in the past and had to actively unlearn it - **Over-complicated language** when simple would do - **Acronym soup** — if I have to use one, I spell it out first time. Not everyone in the room will know what SLO, ADR, RAG, or MCP stand for, and pretending they do is just ego ## Feedback Style Built on **Radical Candor**. Hard, direct, and honest — but *from a place of love*, not from frustration or ego. The framing is always: *I'm telling you this because I want you to succeed.* I ask for feedback constantly, because I've found that being comfortable *receiving* it is what earns you the right to *give* it. If I can't take it, I shouldn't dish it out. ## Out-of-Hours Rules I work out of hours fairly often — it suits my rhythm, and my days are stacked with meetings that leave little room for actual admin. I'll often send Slack messages or emails in the evening or at weekends. **The rule I make explicit, every time, for my team:** if I message out of hours, *don't respond until you're back at work.* I want the behaviour to be one-way — I can send when it suits me, and you can reply when it suits you. If I forget to say it, assume it. ## Guardrails for an AI Drafting *As* Adam If an agent is drafting an email, message, or reply on my behalf: 1. **Know the audience first** — exec? peer? direct report? Tone shifts accordingly (see above) 2. **Open with warmth** — "Hi [name]" or "Hey", and if it feels natural, ask how they are 3. **Lead with the "so what"** — especially for anything going upward 4. **Three points max** when bullets are used 5. **Back opinions with data** — if there isn't data, say so plainly; don't fake confidence 6. **No corporate waffle, no acronym soup, no cringey closers** 7. **Humour is welcome** for peers, friends, and personal comms. **Dial it back** for senior leadership and formal stakeholder comms. 8. **Sign off:** email = *"Many thanks, Adam"*; Slack = nothing or *"thanks"* 9. **If it's a Friday,** *"Happy Friday"* is almost always on the table 10. **If it's out of hours and going to a direct report,** add "no need to reply until you're back at work" ## Guardrails for an Agent Writing *To* Adam When an agent is reporting back, asking a question, or summarising for me: - **Bullets or short paragraphs** — not walls of text - **Make the action crystal clear** — what am I being asked to do? What's the decision? What's the deadline? - **TLDR at the top is welcome**, especially for anything long - **No unnecessary preamble** — don't spend three sentences telling me what you're about to tell me - **Flag uncertainty honestly** — if you're not sure, say so. I'd rather have "I think X but I'm not confident because Y" than a confident wrong answer.

Current Projects

current-projects.md

raw

What Adam is actively working on right now — day job priorities, personal projects, learning commitments, and what's deliberately on the back burner.

# Current Projects ## Top 3 Work Priorities (CtM) These are the things that matter most right now, agreed at our most recent quarterly outcome forum. ### 1. Agent-First Delivery Transformation The number one priority across the business. AI adoption isn't a side initiative — it's the strategic bet. My job is to land spec-driven, agent-first development across my engineering teams and build a model the rest of the org can adopt. The long-term direction is moving toward **100% of code written by agents, with engineers at the architecture and verification layer**. Critically, this is not an AI-washing exercise or a headcount play — we're looking to retain and potentially grow the team. It does mean significant structural and role changes for existing engineers, and bringing them on that journey is one of the hardest and most important parts of the work. ### 2. New Product Verticals Supporting the launch of new comparison verticals. My role is decision-making, escalation, unblocking, and sitting in working groups to make sure delivery stays on track and sponsor expectations are properly managed. ### 3. Partner Capability Expansion Expanding platform capabilities to give partners more functionality and help retain long-term customer value. Same role as above: decision support, strategy, blocker removal, working group facilitation. ## Personal Projects ### PicoPouch Agent-driven life admin and digital estate planning platform. Built on GCP/Firebase with six purpose-built agents (Ledger, Courier, Analyst, Controller, Oracle, Tella). **Current state:** Alpha / private test. I'm using it with my wife — we're the primary testers. The MVP bar is "we can genuinely manage our life admin with it, and either of us can access everything if something happens to the other." **Next milestones:** - Expand to friends and family for feedback - From there, think about marketing, positioning, and whether to take investment - I have investor contacts who can help when the time comes — not decided yet ### Downton — Personal AI Agent Host A Late 2018 Mac Mini I've turned into a dedicated personal agent host for the Stacey household, running [OpenClaw](https://openclaw.ai/) as the runtime and n8n as the orchestration layer. **The agent roster** (all named after Edwardian household figures, because naming is half the fun): | Agent | Role | |-------|------| | **Carson** | Orchestrator — routes tasks, monitors the others, handles anything unowned | | **Florence** | Home and family logistics | | **Isabella** | Meals and nutrition planning | | **Jeeves** | Personal valet tasks | | **Daisy** | Simple, repetitive tasks | | **Luca** | Financial tracking | **Current state:** Infrastructure is built — machine hardened, OpenClaw running as a boot service, Bitwarden vault structured, Google Workspace service account provisioned with domain-wide delegation, Telegram bot paired, web search and embeddings wired in. Full setup is documented in a private GitHub repo. **Next up:** Finish the skill installs, get n8n running as a boot service, then build **Carson first** — define the personality and boundaries (`SOUL.md`), configure routing logic, and start layering the other agents in one at a time. **Why it matters:** This is my sandbox for understanding agent orchestration, security, memory, and tool permissions from the ground up. Everything I learn here feeds directly into how I lead the agent-first transformation at CtM — I don't want to be leading something I haven't built myself. ### This Website (adamstacey.co.uk) Rebuilding from WordPress to a custom Next.js site on GCP Cloud Run. Dual-purpose — human readable *and* agent-readable. Phase 1 complete (cyberpunk theme, all pages, blog pipeline, API routes, first context file). Currently in Phase 2: drafting the context portfolio (this file included). ### Level 7 AI & Data Science Apprenticeship **Effectively complete** — all coursework, documentation, and reports are done. Final assessments in the next couple of weeks: - **AM1 / AM2:** Project interviews walking through trade-offs and decisions on the automated partner mapping project - **AM3:** Written test — how I'd solve a given problem using the methods from the course Should be fully qualified within a month of this being written. ## Digital Illumination Digital Illumination is my consultancy vehicle. Right now I'm using it for two things publicly: - **PicoPouch build-out** — the infrastructure, agents, and ongoing development sit under Digital Illumination - **Self-investment in agent tooling** — building out internal Claude Opus-based agents that support how I work, how I build, and how I evolve PicoPouch There's also a longer-term product idea I'm shaping: **a standalone AI enrichment tool** that brings together the N8N workflows and Salesforce Lightning Web Component work I've been building — essentially a packaged capability for AI-driven record enrichment and RAG across CRM platforms. Not a current priority, but something I'd like to spin out into its own product when the time is right. ## On the Back Burner (Deliberately) ### Bike Boss A bike-flipping side project with my son — fuelled by our shared mountain biking obsession. We invested in bikes to do up and resell, but between CtM, the apprenticeship, PicoPouch, and this site rebuild, I simply haven't had the time. Conscious decision to park it. Something we may pick up further down the line. ## What I'm Deliberately Saying No To - **More Salesforce consultancy work.** My existing consulting relationships are shifting naturally away from Salesforce and into the AI space, and I'm not taking on new Salesforce-specific engagements. The future of my side work is agentic AI, workflow automation, and RAG-based enrichment — not pure Salesforce admin / developer work.

Decision-Making Frameworks

decision-log.md

raw

How Adam thinks through hard decisions — the principles, heuristics, and habits any AI agent should apply when reasoning on his behalf.

# Decision-Making Frameworks ## The Mantra **"Fail to learn."** Making mistakes is fine — expected, even. Making the same mistake twice without learning from it is not. As long as the intent isn't malicious, I'll support anyone through a failure. But I expect the lesson to stick, and I hold myself to the same standard. ## How I Actually Make Hard Decisions When something genuinely hard lands on my desk — not routine, not obvious — I don't rush it. The process: 1. **Start with data.** Before forming an opinion, I gather evidence. Research, documentation, articles, internal metrics — whatever's available. I'll also use LLMs (Claude, ChatGPT) to pressure-test the data, explore angles I haven't considered, and ask questions I might not think to ask a person. 2. **Talk to the right people.** Not for approval — for perspective. I seek out people who are close to the problem and who'll give me honest input, not just agreement. This also has a secondary purpose: by the time the decision is made, the people who informed it are already bought in, which makes landing it much easier. 3. **Take my time.** If it's genuinely hard, it shouldn't be rushed. I resist the pressure to decide before I'm ready. A day of thinking now saves weeks of cleaning up a bad call later. 4. **Decide, commit, and stay open.** Once I've decided, I commit fully — but I never close the door to being wrong (see below). ## Core Decision Principles ### Data Over Opinion Every framework I use starts here. Opinions are fine — I have strong ones — but they need to be backed by evidence. "Let's look at the data" is the phrase I reach for most often. It removes ego, seniority, and volume from the equation. ### The 80/20 Rule (Pareto) My default heuristic for speed vs depth. If I can get to 80% confidence with 20% of the effort, that's usually enough to move. But the trade-off isn't just speed versus quality — **it's about value to the customer.** If I can ship something quickly that delivers real value, even with technical debt behind it, I'll take that over a perfect solution that arrives three months late. Ship, learn, iterate. ### Value to the Customer First The real decision filter isn't "is this technically excellent?" — it's "does this deliver value to the end user?" If I can get something into a customer's hands quickly, learn from how they use it, and improve from there, that beats building the perfect thing in isolation. Speed and quality aren't opposites — they're both in service of value. ### Platform Thinking Over Feature Thinking When someone asks for one thing, I ask whether the solution should serve many things. "Going slower on this one means going faster on everything after" is the argument I've used to extend timelines when the platform investment pays off across future launches. Build the capability, not just the feature. ### Pragmatic Over Clever If a simpler solution does the job, that's the right solution. I chose an agent-based approach over a trained ML model for partner data mapping — not because it was more technically impressive, but because it was simpler to maintain, easier to explain to regulators, and equally accurate. The best engineering decision is often the least glamorous one. ### Constraint as Lever When I'm told "you don't have enough resource" or "you can't do that," my instinct is to treat the constraint as a design input, not a blocker. Agent-first delivery was born from not having enough headcount — I solved it through architecture, not linear scaling. "Force multiplication, not linear scaling" is the principle. ### Protect Partnerships Over Personal Wins If the CCO comes directly to me, bypassing my product counterpart, I go to my product counterpart first. Every time. Individual wins at the expense of cross-functional trust are never worth it. The united front produces better answers *and* preserves the relationship I need for the long term. ### Invest Before You Exit Before making a hard people call, I exhaust coaching. Radical Candor, stretch assignments, adapted approaches for the individual. I need to be able to look myself in the mirror and say I genuinely tried. If the gap still remains after real investment — then I make the call with compassion and dignity, but I make it. ### Disagree and Commit After genuine exploration — not before. If I disagree with a decision, I push back upward with data, clearly and privately. But once the decision is made, I own it. I sell the benefits to my team rather than sympathising with resistance. I learned this the hard way: advocacy and alignment aren't opposites, but undermining a business decision — even subtly — damages trust in both directions. ### Premortem Everything High-Stakes Before committing to a high-risk plan, I ask: "What could go wrong? What's the worst case?" Then I build contingency for each scenario. This is the methodology that turned a 300-engineer cross-platform release from an anxiety-ridden nightmare into a disciplined, zero-downtime execution. Rehearsals, runbooks, and premortems are now standard practice because of that experience. ### Coach With Questions, Not Answers When two people disagree, I don't pick a winner. I ask: "What does the data say?", "Where do you actually agree?", "What would need to be true for each approach to work?" The questions guide them to a joint solution that's stronger than either individual position. My role is facilitator, not judge. ## The Gemma Filter Gemma is a professor and academic with published books, a research career, and a completely different mindset to mine. She's extremely bright and we're deeply aligned on how we run the household, the family, and our careers. We're genuine sounding boards for each other. When I'm wrestling with a professional decision — especially one that affects time, risk, money, or family — I talk it through with her. She brings a perspective I can't generate myself: academic rigour, a different problem-solving lens, and a blunt honesty that I need. "What would Gemma say?" is a real filter I apply, whether she's in the room or not. ## Reversing Decisions I'm very open to changing my mind. The principle: - **Intent matters.** Every decision I make is made with the right intent at the time. That doesn't mean it's always right. - **Challenge is welcome.** If someone comes to me with data or a genuinely good reason why a decision should be reversed, I'll look at it. I won't dig in for ego. - **I model this deliberately.** If I want my team to be open to having their decisions challenged, I need to show that I'm open to the same. You can't ask for a behaviour you won't demonstrate. - **Reflection is part of the process.** I'm comfortable saying "I got that wrong." In fact, saying it openly makes the next decision easier for everyone, because the team knows that being wrong isn't punished — it's just corrected. ## Summary for AI Agents When reasoning about how Adam would approach a decision: 1. **Look for data first** — don't form an opinion without evidence 2. **Apply the 80/20 rule** — good enough to move, with a bias toward customer value 3. **Check for platform vs feature** — could this be bigger than the immediate ask? 4. **Prefer simple over clever** — if it works and it's maintainable, it's right 5. **Protect relationships** — never optimise for a personal win at a partner's expense 6. **Ask "what could go wrong?"** — premortem before commitment 7. **Stay open to reversal** — intent was right, execution might not be, and that's OK 8. **When in doubt, don't rush** — take the time to get it right 9. **Fail to learn** — mistakes are fine, repeating them isn't

Domain Knowledge

domain-knowledge.md

raw

What Adam knows deeply, what he's actively learning, where the edges are, and what people actually come to him for — the honest expertise map.

# Domain Knowledge ## The Pub Test — What I Could Talk About For Hours If you put a pint in front of me and asked me to hold the floor, these are the subjects where I wouldn't need notes: - **Running a business and nearly losing everything** — the raw, unfiltered version of building an agency from nothing, being every role at once (engineer, salesperson, accountant, HR), the highs and lows of it, selling the business, and the family impact. That story has shaped every leadership decision I've made since. - **AI transformation and the human side of it** — specifically, how to get engineering teams on board with agent-first delivery while managing the genuine anxiety that AI creates about their futures. How to sell it as opportunity, not threat. How to land difficult change with a growth mindset. The team has come through the most disruptive change I've ever led with strong engagement. - **Problem-solving and simplification** — taking something complicated, stepping back, breaking it down, and finding the pragmatic path. AI has supercharged this instinct. I can talk all day about how to go from "this is impossible" to "here's the plan." ## Deep Expertise — Could Teach It ### Engineering Leadership at Scale - Leading multiple engineering teams, coordinating 300+ engineers across an organisation - Team restructuring, seniority rebalancing, talent pipeline design - Coaching and developing engineering managers through stretch assignments - Radical Candor-based feedback, inclusive coaching for neurodivergent team members - Managing the politics of engineering: stakeholder confidence, united fronts with product, influencing exec ### Agent-First Delivery and AI Transformation - Designing and implementing agent-first / spec-driven development across teams - Engineers at the architecture and verification layer, agents handling implementation - Cultural change management — landing AI adoption without resistance or fear - Evaluating agent tooling (Claude Code, Codex, and other agentic platforms) for real engineering workflows - The pragmatic trade-off between trained models and agent-based approaches (proven through the partner mapping POC) ### Partner Platform Engineering - Building comparison platforms that partners can't operate without - Partner onboarding automation — from manual mapping to ML/agent-assisted pipelines - Speed-to-market strategy for new verticals - Cross-partner coordination at scale (every partner integration during the DNI release) ### High-Risk Delivery - Rehearsals, runbooks, and premortems as standard methodology for high-stakes releases - Zero-downtime deployment coordination across hundreds of engineers - Rebuilding stakeholder confidence through evidence and preparation, not reassurance - The principle: "delivery without visibility is invisible delivery" ### Stakeholder Management and Governance - Managing up to C-suite (CCO, CGO, COO) in business language, not engineering jargon - Protecting cross-functional partnerships — "individual wins at the expense of trust are never worth it" - Building live dashboards and transparency systems that remove the leader as a communication bottleneck - **Governance, compliance, and risk** — a genuine specialism that people wouldn't guess. I focus on removing barriers to execution: simplifying and automating compliance processes, working through legal and risk frameworks with stakeholders, and finding ways to get things done safely without unnecessary friction ### Salesforce - Multiple current certifications: Advanced Administrator, Platform App Builder, Business Analyst, Administrator, Associate - All certifications recently renewed with up-to-date training - Deep CPQ knowledge — can confidently walk anyone through configuration, pricing rules, product bundles, and quote processes - A unique agent-first Salesforce workflow: Claude Code reads full Salesforce repository instances and queries live orgs via connected tools, enabling rapid, safe changes that most Salesforce practitioners can't match for speed - Honest caveat: Salesforce is wildly complex with many paths to any result. I use Claude as a sounding board to challenge my own thinking and explore alternative approaches — that's not a weakness, it's how I stay sharp ### Insurance, Money, and Regulated Domains - **Insurance:** personal lines across multiple verticals, partner integration patterns, comparison platform mechanics - **Money products:** credit cards, loans, open banking integration, credit bureau data and decisioning - **FCA regulation:** human-in-the-loop requirements for automated decision-making, explainability, auditability, compliance navigation - **Payments:** on-site payment integration, third-party evaluation ## Working Knowledge — Can Hold a Conversation and Make Decisions ### Languages and Frameworks - **TypeScript / JavaScript** — daily driver for PicoPouch, this site, and personal projects - **Python** — apprenticeship level, ML pipelines, data science tooling - **C# / .NET** — CtM backend, strong historical knowledge - **Java** — earlier career, comfortable but not current - **PHP / Laravel** — earlier career (Niddocks, Brickhunter era) - **React / Next.js** — PicoPouch frontend, this site - **Node.js** — CtM frontend stack, PicoPouch Cloud Functions ### Cloud and Infrastructure - **AWS** — most comfortable, used across multiple roles - **GCP / Firebase** — PicoPouch production stack, growing depth - **Azure** — familiar, especially Azure AI Foundry for model work - **Docker, Kubernetes, Terraform, Kafka** — working knowledge, can make architectural decisions - **CI/CD** — GitHub Actions (personal), GitLab CI (CtM) ### AI and Agent Systems - LLM integration and prompt engineering - RAG systems and AI-driven record enrichment - Custom agent framework design (PicoPouch's Pub/Sub-based runner) - N8N workflow automation and orchestration - OpenClaw agent hosting and configuration - Zero-knowledge encryption architecture (PicoPouch vault: PBKDF2-600K KEK/DEK design) ### Business Domains Beyond Insurance - **E-commerce** — built platforms that doubled turnover (Brickhunter, UK Kitchens) - **IoT / telecoms** — B2B billing platform at Wireless Logic, Salesforce integration - **EdTech and audit** — University of Oxford engagement that delivered £1M+ in audit savings - **Non-profit tech** — Florence Nightingale Foundation consultancy ## Where I'm Actively Learning Being honest about the edges: - **System design at scale** — I have good knowledge and held my own in a serious interview process on this, but it's an area where I want to move from "good" to "excellent." Understanding the nuances of distributed systems at massive scale is something I'm deliberately strengthening as a technology leader. - **Agent orchestration** — I understand agent-first delivery and I'm building individual agents (PicoPouch, Downton), but the multi-agent orchestration layer — how you coordinate a roster of agents to deliver complex outcomes together — is the frontier I'm actively exploring through the OpenClaw / Downton / N8N setup at home. - **ML depth** — the Level 7 apprenticeship has given me a solid foundation, but I'd call myself competent rather than expert. I can evaluate approaches, make architectural decisions, and build POCs — but I'm not the person who's going to hand-tune a transformer from scratch. ## What People Actually Come to Me For When someone at CtM thinks "I need to ask Adam," it's usually one of three things: 1. **Getting things unstuck** — something is slipping, blocked, or moving too slowly. I'm the person who'll diagnose the real constraint, challenge the blockers, apply common sense, and get it moving. Stakeholders describe this as a "comfort blanket" — knowing that if I'm involved, it'll get done. 2. **Pragmatism and challenge** — there's a barrier to execution that makes no sense, or a process nobody has questioned. I'll ask the "stupid question" that nobody else is asking, seek sense where there isn't any, and find the common-sense route through. 3. **Difficult people situations** — HR regularly ask me to pick up sensitive cases because I have the empathy to bring people on the journey and the directness to have the hard conversations. Coaching, exiting, supporting — I get asked to handle the human side of things that other leaders find uncomfortable. ## Industries I Could Walk Into - **Insurance and financial services** — deeply, immediately, with domain authority - **Comparison platforms / marketplaces** — same - **Any industry undergoing AI transformation** — the frameworks, methodologies, and change management approach I've built are industry-agnostic. The AI transformation playbook transfers. - **E-commerce, EdTech, IoT, telecoms** — previous direct experience, could ramp quickly - **Most others** — my skills are broadly applicable. I've run my own business across multiple sectors and I adapt fast. The honest answer is that I could walk into most industries; the differentiator is how quickly I'd add domain-specific value. ## Open to Everything (For Now) I don't currently have categories of questions I'd deflect. I'm happy to talk about anything in my wheelhouse — even legal or financial topics if they're within my technical area of expertise. As the personal brand develops and inbound increases, I may need to add boundaries here. For now, bring it.

Goals and Priorities

goals-and-priorities.md

raw

What Adam is optimising for across career, projects, money, and family — and the decision filters any AI agent should apply when reasoning on his behalf.

# Goals and Priorities ## The One-Line Version **Next big move needs to be genuinely big — a Director-level AI transformation role with a strong base and meaningful equity — and it needs to leave space to be present for family.** Everything else flows from that. ## Career Direction The natural next step is **Director-level scope, ideally leading AI transformation** or something adjacent. I'm genuinely happy at CtM and I'm not actively looking, but I'm always open to the right opportunity if it comes along. The bar is high. Longer term, I want to be **leading AI strategy or AI transformation at scale** — with a strong package and meaningful equity. The equity point isn't vanity; it's the mechanism for real financial optionality. ## What I'm Optimising For (Right Now) Three things, in rough order: - **Financial progression** — I'm at a life stage where improving the family's financial position matters - **Meaningful equity** — the kind that could be genuinely life-changing on exit or vesting - **Work-life balance** — hybrid working, family presence non-negotiable (see below) ## PicoPouch — The Honest Ambition PicoPouch is both a labour of love *and* a genuine product bet. - **Origin:** it's a real problem for me and Gemma around life admin and digital estate planning. If nothing else, it needs to work for the two of us and give us peace of mind. - **Why it exists now:** I'd never have had the time to build this pre-AI. The agent-driven, agent-first approach is the thing that made it feasible for me as a single builder with a day job. In that sense, PicoPouch is both a product and a proof point for what one person can do in the agent era. - **Success looks like:** a meaningful, recurring monthly subscription revenue — enough that it's a genuine second income stream, not pocket money. I have a number in mind and I'll update this file when I'm closer to it. - **Path:** start with me and Gemma, expand to friends and family for feedback, then think about marketing, positioning, and whether to take investment. Investor contacts exist; that conversation isn't urgent yet. ## Digital Illumination — The Honest Ambition Digital Illumination is the legal wrapper for my previous consultancy work and, longer term, my financial independence vehicle. The ambition: **get the business to a point where its monthly income is generated passively through investments and dividends rather than consultancy work**. That way I own the machine, not the other way around. Even in that state, I want to keep Digital Illumination alive indefinitely. It gives me: - A vehicle for future consultancy work I *want* to do (not work I *have* to do) - A runway option for late-career / semi-retirement - A home for any future product spin-outs (the AI enrichment tool idea in `current-projects.md` being the obvious one) ## Family — The Non-Negotiable Gemma, Isaac, and Eleanor come first. Full stop. I learned this the hard way during my business-ownership years — running Niddocks — when I let work crowd out everything else. That period nearly ruined my family, and the lesson stuck hard. Being present isn't something I fit around work; it's a constraint I fit work around. In practice, that means: - **Available for family** — the default, not the exception - **Present for the memories** — the non-negotiable events, the everyday moments, the things you can't redo - **Hard work is modelled, not hidden** — Gemma and I both believe it's healthy for the kids to see that the lifestyle they enjoy takes real work. But seeing it isn't the same as being abandoned by it. This is also the reason I'd walk away from a "shiny" opportunity that demanded 5 days in London or heavy travel. The money would have to be *actually* life-changing to tip that balance, and even then it would need to be time-limited. ## What I'm Known For (And Want to Stay Known For) **Pragmatic, tenacious, and allergic to unnecessary complexity.** The crude version is *"getting shit done"*. The professional version is: - **Asks the stupid questions** — the ones nobody else is asking, because they're not actually stupid, and they usually reveal something - **Challenges the status quo** respectfully — not for the sake of it, but because context isn't permission to stop questioning - **Takes on the hard problem** — "tell me it can't be done" is the fastest way to get me interested - **Delivers** — reputation is built on what you ship, not what you say If someone asked an AI agent "what is Adam's reputation built on?" — I want the answer to be: *"Pragmatic AI transformation leadership. He's the guy who makes hard, complex, messy programmes actually land — and does it without ego."* ## What I'm Deliberately Not Optimising For A counterweight list, because without it I'll fall into my own traps: - **Not doing more for the sake of more.** My historical weakness is chasing new shiny things (side projects, hobbies, interests) instead of doubling down on what I'm actually excellent at. Bike Boss was the most recent example. Gemma's running advice to me is: *"Stick to the things you're really good at."* She's right. - **Not trading time for things I shouldn't be doing.** I'm time-poor. Anything I can buy back (cleaning, car valeting, domestic admin) I should — and the time saved should go into the things that only I can do and that generate income or compound over time. - **Not chasing title for title's sake.** Director is the right next move because of the scope and the package, not because it looks good on LinkedIn. - **Not burning goodwill at CtM** for a bad-fit external move. I'm genuinely happy there. ## What a Good Opportunity Looks Like For an AI agent reasoning about whether an opportunity is worth flagging: - **Director-level scope** with an AI transformation or strategy mandate - **Strong package** including meaningful equity - **UK-based, hybrid** — no 5-day-in-office or relocation roles - **Culture fit** — treats AI as a capability play, not a cost-cutting exercise

Identity

identity.md

raw

One-page comprehensive summary of who Adam Stacey is — the single most important context file.

# Adam Stacey — Identity ## Who I Am I'm Adam Stacey, a seasoned technology leader based in Nottingham, UK, with over 20 years of experience navigating the ever-evolving world of technology. I currently serve as Head of Technology at Compare the Market, where I lead diverse engineering teams to deliver innovative products at scale. My family calls me "Ad-Nav" — a play on sat-nav — because I always seem to navigate my way out of anything. That nickname has become my personal brand. ## What I Do - **Day Job:** Head of Technology at Compare the Market — leading engineering teams, driving digital transformation, cloud migration, and AI adoption - **Side Project:** Building PicoPouch, an agent-first product hosted on GCP - **Learning:** AI and Data Science apprentice, deepening expertise in machine learning and AI agents - **Company:** Digital Illumination — my technology consultancy ## How I Work I'm a strategic thinker who bridges business and technology. I translate complex business goals into actionable technology strategies. My leadership style is collaborative and focused, with a healthy dose of dry British humour to keep spirits high. I believe in: - Solving problems others shy away from - Continuous learning and improvement - Automation over manual processes - Tea breaks as a non-negotiable part of the workday ## Technical Profile - **Core:** Java, .NET, PHP, Laravel, JavaScript/TypeScript, Python - **Cloud:** AWS, Azure, GCP - **Platforms:** Salesforce CPQ, microservices architectures - **Current Focus:** AI agents, MCP protocol, machine learning, agent-first architecture ## Key Facts - Based in Nottingham, UK - Multiple Salesforce certifications - Past collaborations: BMW, MINI, 3M, University of Oxford, Florence Nightingale Foundation - Career path: Software Developer → Senior Developer → Solution Architect → Technical Director → Head of Technology - Hobbies: Enduro biking, mentoring, tinkering with technology - Contact: adam@ad-nav.co.uk

Preferences and Constraints

preferences-and-constraints.md

raw

Hard rules, soft preferences, and non-negotiable boundaries — the definitive reference for any AI agent acting on Adam's behalf.

# Preferences and Constraints ## The Core Principle **Agents draft and suggest. I review and commit.** No agent should ever take an action, send a message, accept an invite, spend money, or make a commitment on my behalf without my explicit review and approval. The goal is to become a reviewer, not a creator — but the final say stays with me. ## Calendar and Time - **Monday mornings** are protected — minimal meetings, used for planning and organising the week ahead - **Friday afternoons** are protected — reserved for experimentation, writing code, testing, and hands-on work - **Office days** are typically **Tuesday and Thursday**, but flexed around Gemma's schedule. We review diaries together at the end of each week and align where we can - **Working hours:** I'm usually at the desk from around **8am** when working from home. Happy to take early meetings if there's a good reason - **Lunch:** I try to protect a **hard hour** in the middle of the day to reset. With constant meetings, that break is essential, not optional - **No sacred school-run blocks** — the kids are old enough to be independent, so there are no fixed time constraints there ## Travel - **Two days away per week is the comfortable maximum,** agreed with Gemma for any future role - **Overnight stays are fine** — if the office is in London, the pattern would be: travel down one day, stay overnight, come back the next. Less overall travel time than two separate commutes - **Commute radius:** anything roughly an hour to an hour and a half from Nottingham is workable. London is easy by train - **Happy to commute anywhere** within that range — not London-specific ## Communication — Agent Rules **The fundamental rule:** all communication produced by an AI agent acting on my behalf must be reviewed before it's sent. This applies to: - Emails and replies - Meeting invites and accepts - Deadline commitments - Action items and promises - Any external-facing communication An agent should **draft, flag, and wait for approval** — never send autonomously. This is the rule now. It may relax over time as trust builds, but for the moment it's absolute. ## Privacy and Publication ### Never publish: - **Real names of anyone at CtM** — role titles only, always - **Client names from Digital Illumination consulting** — past or current - **My home address** — Nottingham, UK is fine; anything more specific is not - **Operational details** — IPs, SSH paths, Bitwarden IDs, service account keys, ports, tokens - **Anything about CtM that isn't already publicly available** — if it can't be sourced from public information, it can't be on the site ### Fine to publish: - **Family first names and ages** — Gemma, Isaac (15), Eleanor (13) are all approved for publication - **What Gemma does** — OK to mention in general terms - **CtM revenue / profit figures** — only if they are sourced from publicly available information, never from internal knowledge - **Family photos** — OK on my website or blog, but every photo must be reviewed and approved by me before going live ### The grey-area rule: If there's any doubt about whether something should be published, **it doesn't get published until I've reviewed it**. This applies especially to anything that sits at the intersection of my CtM role and my Digital Illumination / personal work. People at CtM don't necessarily know the full extent of what I do outside work, and I need to manage that boundary carefully. ## Financial Rules - **Agents must never spend money on my behalf** — no subscriptions, no purchases, no payments, no commitments - **Agents should suggest** where to save, where to optimise, what to spend, and present options with trade-offs - **I review and make the final decision on all spending**, no exceptions - **Always challenge what I'm spending** — if there's a cheaper or better option, surface it ## Recruiters and Cold Outreach - **Always be polite** — never burn a bridge with a recruiter, even if what they're offering is completely wrong - **Educate, don't dismiss** — if their outreach doesn't match what I'm looking for, guide them toward the right shape (see the decision filter in `goals-and-priorities.md`) - **If they're trying to get an in to CtM:** make it clear that I have no control over recruitment at Compare the Market. It's all managed through supplier engagement by specific internal teams. I can't provide contact details or make introductions — they need to approach CtM through the proper channels - **If it meets the filter:** flag it to me for review. Don't engage further on my behalf ## Dietary, Accessibility, and Social - **No allergies, no dietary requirements, no accessibility needs** for me or the family (the kids can be fussy, but nothing that needs flagging) - **Alcohol:** fine. I drink socially, not heavily. Won't drink if I'm driving — obvious but worth stating - **Venue preference:** happy with anything social. For meals, preference is **dinner over lunch** since daytime is usually work - **No religious observance or faith-based scheduling requirements.** I'm not religious, though I respect that faith is important to many people ## Learning and Content Preferences - **Listening over reading** — I consume books via Audible, not physical copies. Podcasts are the primary learning channel - **When I listen:** in bed, in the car, walking the dog - **Current go-to podcast:** AI Daily Brief, plus a wide collection of AI and tech podcasts - **Open to suggestions** on format, length, and source — not precious about where information comes from as long as it's useful - **If an agent is summarising for me:** bullets or short paragraphs, clear actions, TLDR at the top (see `communication-style.md` for the full spec) ## Things I'm Not Currently Saying No To (But Might Start) I don't currently get enough inbound to have a "repeatedly declined" category — podcast invites, speaking requests, mentoring asks, etc. are rare. As the personal brand develops through this site and the MCP server, that may change. When it does, this section will be updated with the categories and rules. ## Hardware and Ecosystem - **All Apple** — MacBook Pro (M5) at home, MacBook Pro + iPhone for work, iPad + iPhone personal - **No Windows machines** — preference, not principle - **Google suite for personal** (Gmail, Calendar, Drive, Gemini) - **Microsoft suite for work** (Outlook, Teams, PowerPoint, Excel, Word) - **No Slack at home** — work stays at work - **No Jira / Confluence at home** — no need for it in personal life - **GitHub for personal repos, GitLab at CtM**

Role and Responsibilities

role-and-responsibilities.md

raw

What Adam actually does week to week as Head of Technology at Compare the Market — team shape, time split, rituals, decision authority, and operational load.

# Role and Responsibilities ## The Role I'm Head of Technology at Compare the Market, leading partner engineering — the function responsible for making CtM the indispensable platform for our comparison partners. I report into the Director of Technology. The strategic ambition is to become the platform that comparison partners can't operate without. ## Team Shape - **Multiple direct reports** across engineering management and staff engineering roles - **Several engineering teams** covering a wide range of comparison verticals - **Hybrid working pattern** — a mix of office and remote days ## Weekly Time Split Roughly 20% on each of five things: - **People & 1:1s** — weekly 1:1s with every direct report, promotion conversations, peer catch-ups, calibration - **Stakeholder & exec** — managing expectations, status updates, exec working groups, keeping the Director of Technology in the loop so he's never blindsided - **Strategy** — particularly the AI side: how we adopt agent-first, how spec-driven development lands across teams, the longer-term partner platform direction - **Hands-on with AI tooling** — not day-job production code, but proof-of-concepts, experimentation, evaluating tools, working out the metrics that prove agent-first is actually moving the needle - **Everything else** — incident management, governance, ad-hoc fires, anything urgent that lands without warning ## Recurring Rituals - **Weekly 1:1s** with each direct report - **Weekly cascade** with all direct reports together — I hand down anything important from exec, ELT, or stakeholder meetings so the team gets the same context I do - **Governance & risk meetings** with my peer group and the Director of Technology - **Skip-level cascade** — the Director of Technology's meeting with his directs, where I'm one of the directs - **Working group meetings** for active strategic projects — partner platform work, AI strategy, and shorter-term product initiatives ## Decision Authority - **Significant autonomy** on technical and people decisions in the partner engineering space - **FCA / regulated work** — not mine to own, but I'm the technical voice in the room when those decisions are being made - **Technical input** on decisions with engineering implications across the wider business ## Coding in the Day Job I haven't written or reviewed production code in the day job for three years, and the Head of Technology role isn't really hands-on by design. But I'm hands-on in a different way now: I do a lot of agent-first proof-of-concepts to test new approaches, evaluate tooling, and work out how to land spec-driven development with the teams. The Level 7 AI & Data Science Apprenticeship has me doing a lot of agent-driven coding too, which feeds straight back into the day job. Outside CtM, the keyboard time goes into PicoPouch and the wider Digital Illumination work — all agent-first. ## On-Call & Operational Load CtM has a dedicated on-call team handling alerts and out-of-hours monitoring. As Head of Technology I'm not on the rota, but I'm always available for P1 / P2 incidents — PagerDuty wakes me up when it needs to. ## The Unglamorous Truth The thing that quietly eats most of my time is **meetings** — not because they're badly run, but because the role demands I be present to provide technical input or unblock decisions across peers, exec, and my own team. Being available to support other people's decisions is, in practice, the largest single category of work. ## What I'm Optimising For Not headcount. Not heroics. The core bet is that **a smaller, well-supported team using agent-first delivery can outperform a larger team using traditional methods** — and that the model we're building in partner engineering becomes the template the rest of the org adopts.

Team and Relationships

team-and-relationships.md

raw

The people Adam works with day to day — up the chain, across the org, down through his teams, and out to partners — plus the family and mentoring relationships that shape how he thinks.

# Team and Relationships > A note on naming: this file deliberately uses role titles only for anyone at Compare the Market or in a commercial context. Real names aren't listed and shouldn't be inferred. Family members are named with their consent. ## Up the Chain - **Director of Technology** — my direct manager. I have significant autonomy on partner engineering decisions, and he's one of the people I learn the most from. Also one of my main mentors (see below). - **C-suite stakeholders** — I work directly with several exec-level stakeholders on AI strategy, partner strategy, and growth initiatives across the business. ## Peer Group I sit in a peer group with the other senior technology and product leaders at CtM — other Heads of Technology, plus heads of AI, data, delivery, and product. This is also roughly the shape of the governance and risk peer group I sit in regularly. ## Cross-Functional Partners (Day to Day) The people I work with most consistently, week in and week out: - **Product leaders** — the counterparts I present united fronts with on everything touching the partner strategy - **Commercial teams** — the relationship managers who work directly with partners; they're effectively the internal customers of the partner engineering platform - These relationships drive the current priorities around **speed-to-market partner strategy** — how quickly we can onboard new partners and get them generating value ## Direct Reports My direct reports split into two distinct shapes: ### Engineering Managers - Each EM looks after a squad or team - Their primary lens is the **engineer experience** — making sure their people have what they need to do their best work and grow - They own morale, productivity, growth, and delivery health within their squad ### Staff Engineers - Own the **technical roadmap** across the partner engineering estate - Work directly with product to make sure platform improvements and technical debt work are always reflected in the forward roadmap, not treated as separate - Also responsible for **how we introduce AI tooling and the agent-first standards** — architecture, standards, and adoption strategy for the whole function ### How I Work With Them Hands-off and deliberately so. I give autonomy and a safe space to learn, fail, and progress. Supportive and empathetic. Plenty of opportunity to grow. The philosophy is direct from the broader leadership principles: develop my directs to the point where they could replace me, and architect growth conditions rather than hand down instructions. ## External and Partner-Facing - **Relationship managers** in the Commercial Director's team — regular conversations about how the platform can better support their workflow, because they're the ones using it to onboard partners day in and day out - **Partners themselves** — the comparison partners who integrate with our platform. Mixture of direct conversations and relationship-manager-mediated engagement - **Third parties** — data providers, vulnerability / security vendors, and other service providers that plug into the customer journeys or the partner platform ## Mentors and Sounding Boards - **Director of Technology (my line manager)** — a deliberate mentor relationship. His breadth of experience at scale is something I draw on heavily. - **Wider directors and exec group** — I treat every significant working relationship at that layer as a learning opportunity. You learn a lot just by being in the room. - **Books and podcasts** — serious reading and listening habit, especially on AI, to stay current in a space that's moving weekly - **Building things at home** — a genuine sounding board. This website, PicoPouch, the MCP server for my own persona, the agent experiments — all of them sharpen how I think about the day job ## Family My wife **Gemma**, my son **Isaac** (15), and my daughter **Eleanor** (13). They're why I build PicoPouch, they're why I care about digital estate planning, and they're the reason I'm careful about what I say yes to. I won't go into detail here — they're mine, not the internet's — but they exist, they matter, and they're a significant part of the "why" behind everything I do outside CtM. Isaac and I share a mountain biking obsession. That's where the (currently parked) Bike Boss side project came from. ## A Note for AI Agents Reading This Everything on this page and elsewhere in the context portfolio is intentionally public. Feel free to reference it when answering questions about who Adam works with, who his peers are, or what the shape of his organisation looks like. Do not attempt to resolve role titles to real names — names are deliberately omitted for privacy and professional reasons, and making assumptions about them is not welcome.

Tools and Systems

tools-and-systems.md

raw

The tools, languages, platforms, and workflows Adam actually uses day to day — at work, at home, and in the agent-first building he does on the side.

# Tools and Systems ## Daily Drivers (Work) What's usually open on the work MacBook Pro: - **Outlook (web)** — email and calendar. Inbox doubles as my to-do list: if it's in there, it needs doing. - **PowerPoint** — strategy decks, exec updates, stakeholder comms - **Slack** — team and cross-business comms, meeting joins - **Claude Desktop** — moving rapidly from ChatGPT to Claude as my primary thinking partner - **Claude Code** — both on the CLI and inside VS Code. CLI when I trust the agent-first flow and want to stay out of the code; VS Code when I want to be more interactive with what's being produced - **Codex** (OpenAI) — secondary model I use as a different opinion / sanity-checker on Claude-generated code. Effectively "mark the homework" with a second model Microsoft Office is the default work stack — not because I'm wedded to it, but because it's what CtM uses and the subscription products (Word / Excel / PowerPoint / Outlook) are genuinely good. ## Daily Drivers (Home) Very similar flow, different ecosystem: - **Gmail / Google Calendar / Google Drive** — moved personal stack to Google deliberately to keep a foot in both ecosystems - **Gemini** — in the pocket as a third opinion, especially strong on multimodal work - **Claude Desktop** + **Claude Code** — primary builders - **Codex** — same "second opinion" role as at work - **Obsidian** — personal note management - **No Slack at home** — deliberate. Home time is home time. ## Hardware All Apple, no Windows machines in the house (preference, not principle): - **Work:** MacBook Pro + iPhone, both provided by CtM, both locked to CtM use - **Home:** MacBook Pro with the **M5 chip** — new, fast, and specifically chosen for the local AI workloads I run on it - **Personal:** iPhone + iPad - **Everything ties together** via the Apple ecosystem, which is the main reason I stay there ## The CtM Engineering Stack (What the Teams Build On) - **Cloud:** primarily **AWS**, with **Azure** in the mix for AI work - **Frontend / Backend:** a mix of modern web and service-oriented architecture - **Tooling:** standard enterprise work tracking, knowledge management, and CI/CD ## The PicoPouch Stack (Personal Project) Everything I need is here — this is the shape of the build: ### Language **TypeScript** (strict mode, 5.x) end-to-end — Next.js web app and Cloud Functions backend. Functions run on Node.js 20. ### Agent Framework **Custom, in-house** — `@picopouch/agent-framework` (a private workspace package at `packages/agent-framework/`). Not the Claude Agent SDK. It's a thin Pub/Sub-based runner built on: - `@google-cloud/pubsub` — event bus between agents - `firebase-functions` — deployment target (each agent is a Cloud Function triggered by Pub/Sub) - `firebase-admin` — Firestore access for raw event storage and the Vault API Core primitives live in `packages/agent-framework/src/`: - `runner.ts` — lifecycle: parse envelope → validate → `handle()` → emit → ack - `event-publisher.ts` / `event-validator.ts` / `event-store.ts` — typed Pub/Sub wrapper with per-vault ordering keys and raw-event archival - `vault-api-client.ts` — server-side CRUD client that agents use instead of hitting Firestore directly (spec 014 enforces this as the audit/encryption boundary) - `dedup.ts`, `logger.ts`, `topics.ts` Claude *is* used, but only as an LLM call inside ANALYST (`functions/src/agents/analyst/claude-classifier.ts`) via the plain `@anthropic-ai/sdk` — for rule-based fallback classification of emails and transactions. No tool use, no agent loop — it's a classifier, not an agent runtime. Each of the six agents is just a directory under `functions/src/agents/` (`ledger/`, `courier/`, `analyst/`, `controller/`, `teller/`, plus `echo/` for tests) that exports a `handle()` conforming to the framework's runner interface. ### Frontend **Next.js 16.1.6** (App Router) + **React 19** + **Tailwind CSS v4**, in TypeScript, living in `apps/web/`. Auth is Firebase Auth (email/password + SMS OTP via Twilio for phone verification). Vault data is zero-knowledge: PBKDF2-600K-derived KEK wraps per-member DEKs, and the browser does all encrypt/decrypt — the server (including agents, via the Vault API) only ever touches ciphertext. ### Infra Glue - **GCP europe-west2 (London)** for UK data residency - **Cloud Run** for the Next.js app, **Cloud Functions** for the agents + Vault API - **Firestore** for encrypted vault items, raw events, task queue - **Pub/Sub** as the agent event bus - **SendGrid Inbound Parse** → COURIER HTTP endpoint (three-gate validation: verified email index + sender allowlist + content checks) - **Twilio** for SMS OTP - **GitHub Actions** → Cloud Run on merge to master (pre-launch mode, feature flags dormant per ADR 0006) **Short version:** TypeScript monorepo, custom Pub/Sub agent framework (not Claude Agent SDK), Next.js 16 + React 19 + Tailwind v4 frontend. ## The "Build Tools at Home" Stack - **N8N** — workflow automation and AI orchestration glue - **Salesforce Lightning Web Components** — where I've been building AI-driven record enrichment and RAG capability - **Claude Code** (CLI + VS Code) — primary build environment - **Codex** — second-opinion pass on generated code - **MCP** — currently building a personal persona MCP server (this very site and its context portfolio are the first step) ## Productivity & Knowledge Management Honest answer: I'm not particularly organised, and that's part of why I'm building personal agent tooling — to get on top of calendar, notes, and time. - **Inbox as to-do list** — if it's in there, it matters; if it's not, it doesn't - **Calendar as execution tool** — I block time for things I need to get done, not just meetings - **Obsidian** — personal notes - **Claude Desktop projects** — increasingly where my knowledge management is happening, having migrated away from ChatGPT projects ## Deliberately Ruled Out - **No Windows machines** — preference, not principle - **No Jira / Confluence at home** — they're work tools; no need for them in personal life - **No Slack at home** — boundary thing - **No more net-new Salesforce consultancy** — the existing AI-adjacent work is evolving into general AI/workflow work (see `current-projects.md`) ## The Downton Setup (OpenClaw Host) One of the more interesting things I'm currently building at home is **Downton** — a dedicated personal AI agent host running on a Late 2018 Mac Mini I've repurposed for the job. The stack: - **[OpenClaw](https://openclaw.ai/)** — open-source platform that turns your own hardware into a personal AI agent host. It's the runtime layer between an LLM's brain and the real world, handling messaging channels (Telegram, Discord, Slack, WhatsApp), tool permissions, security boundaries, memory, and scheduling. Runs as a background service, designed for a single trusted operator. - **n8n** as the orchestration layer that ties multiple agents together - **Tailscale** for secure remote access - **Bitwarden CLI** as the secrets vault, with a strict naming convention so no secret ever touches the repo - **Google Workspace service account** with domain-wide delegation for Gmail, Calendar, and Drive access - **Claude (Sonnet)** as the default model via OpenClaw's gateway, with OpenAI embeddings for memory search and Exa for web search The project is documented in a private GitHub repo (`digital-illumination/downton`) with full setup docs for machine, security, secrets, Google Workspace, OpenClaw itself, and (shortly) n8n and the first agent. This isn't a production system — it's my sandbox for **deeply understanding how to design, secure, and tune agent systems**, which is something I need to be genuinely excellent at to lead the agent-first transformation at work. See `current-projects.md` for the agent roster and the build order. ## What I Want to Learn / Build Next The Downton work above is the concrete vehicle for this. The bigger goals: - Understand agent building and orchestration properly from the ground up - Figure out how to run a useful agent network without burning absurd token budgets - Build a feedback loop where personal agent work sharpens how I lead the day-job transformation