Your Personal Context Layer

If you swapped out your AI tomorrow for a newer, smarter one, how much of your work would actually survive the switch?

For most of us, the honest answer is: not much. We treat AI as a conversation. You open a chat, explain everything, get a useful answer, then start over the next day. The model is brilliant and remembers nothing about how you work.

In Theory

I’ve started treating it differently. Less like a conversation, more like a collaborator I onboard. And onboarding material has to live somewhere.

For me, that somewhere is one organized space: the inputs, the outputs, the decisions, the running history of a piece of work, all in one place. I think of it as my personal context layer. Whatever AI I bring in can pick up where the last one left off without me having to re-explain who I am or what we are doing.

The shift is subtle, but it changes everything. The real leverage was never the model. It is the context around it. Models are rented and increasingly interchangeable. Your context is yours.

That is also the test. If you swapped models and your know-how came along for the ride, you have built something durable. If all your output was riding on the raw power of the model you happened to rent, you never really had an edge.

The organizations that win with AI will not be the ones with the best model. They will be the ones with the best-organized context. The same goes for you.

So before you chase a better model, it is worth asking: have you built a place worth bringing it into?

In Practice

That is the theory. Here is what it actually looks like.

Project Flow within the Context Layer

Every project I run lives in the same shape. Open any one of them, and you find the same six pages, in the same order. Everything lives in Notion.

First, a Setup page. This is the onboarding doc: what this project is, what to read, and the order in which to read it, before doing anything. A new hire reads it and is oriented in a minute. So is the AI.

Then a Project Brief, which is just where things stand right now. Not the history, the current state. If I have been away a week, this is the page that catches me, or the model, back up.

Next, an Action Log. Every task, with a simple marker for done, pending, or dropped, newest at the top. Nothing gets re-litigated because the decisions are already written down. When I ask, “Where were we?” the answer is on the page.

Alongside it, a Change Log for the structural stuff: when I rename something, retire an old convention, or change how the project works. It is the difference between “we changed our minds” and “we forgot we changed our minds.”

And two pages that bookend the work itself. An Inputs page for the raw material it draws on, as well as the source documents, notes, and references. An Outputs page for the finished work, kept apart so the source and the result never blur.

That is the whole system. Six pages, repeated across every project. Plus one thing I never skip: my Prime Directives. A short, fixed set of instructions every AI reads and accepts before it touches anything. My guardrails. My unwavering truths. My value system.

None of it is clever, and that is the point. The leverage was never in being clever. It was in being organized enough that the next session, with any model, would pick up exactly where the last one left off.

What the AIs think (in their own words)

Here is the honest scorecard, after running this way for a while. Some of it has worked better than I expected. Some of it has not.

What works. The cold start is the biggest payoff. I can drop a new AI into a project, point it at the Setup page, and it is useful in minutes instead of an hour of re-explaining. Decisions also stop slipping. When the Action Log says something shipped, it shipped, even when my memory says otherwise. More than once, the files have corrected me, not the other way around. And because the inputs and working notes already live in the project, drafting starts with real material rather than a blank page.

What does not. The whole thing runs on discipline, and discipline is the first thing to slip. A log nobody updates is worse than no log, because it lies with confidence. Keeping it current is real, unglamorous work. The tooling is fiddly too: an edit quietly fails to save, and you only catch it if you go back and check every time. When two of us edit the same page at once, we collide. And the structure drifts. Rename something in one place, and three other pages still point at the old name weeks later.

The honest take. The system does not make the work smarter. It makes it continuous. The benefit is not intelligence; it is memory and momentum, the ability to stop and restart without paying the re-explaining tax each time. The cost is the upkeep. For anything I will touch more than a few times, that trade is worth it. For a one-off, the ceremony is not.

What I found (in my own words)

A year of living with this system has taught me more than the system itself ever did. I built the context layer so I could run any model over it. The work now is quieter: reducing drift, lowering the cost of upkeep. That is where the real returns are.

The thing I keep relearning is that AI is clever but not smart. It makes dumb mistakes in the places you would never think to check, and it delights you in the places you expected nothing. You learn to treat it accordingly.

If I strip the year down to the lessons that actually earned their place, six remain.

  1. Don’t trust memory. It corrupts quietly and derails you without warning. If it matters, write it down where the next session can find it.
  2. Trust your gut. If an output smells off, it is off. That instinct is usually faster than the proof, so stop and check.
  3. Stay the editor. Never just accept what comes back. Keep cutting, keep reshaping, and make it show its reasoning.
  4. Load your prime directives first. Before anything else happens in a session, the guardrails go in. Everything good downstream depends on it.
  5. Keep the boundaries up. Hold each project inside its own walls. It is what stops the drift, the bleed, and the quiet duplication.
  6. Keep it simple. AI will always over-recommend. Chop it back to what is real, then chop it again.

Six, not because there aren’t more, but because a short list is one I will actually follow. That is the whole point.

What’s next

A context layer that holds steady sets up the next phase. Not just me and a model, but shared work: co-workers and scheduled tasks drawing on the same context through one shared endpoint. For now, I am deliberately keeping my hands on the wheel, running the operator function myself, and logging every place the AI makes a bad call. Those notes are turning into specifications, and those specifications will be the inputs for the autonomous agents that are now coming online.

Which brings me back to where I started. The model you rent will keep changing, and the next one will always be smarter than the last. What stays is the place you bring it into. Build that place well, and every upgrade compounds on a foundation you already own. Build nothing, and you start from zero every time, no matter how good the model gets.

So before you chase a better model, build a place worth bringing it into.

Posted in AI | Leave a comment

Two operating models, one company

AI has made the old transformation question sharper. If you run a mature company, do you keep repairing the legacy operating model or build an AI-native one beside it?

For most incumbents, the answer is not either/or. It is a transformation and a twin. One model keeps the business reliable, compliant, and profitable. The other learns how work should function when cheap intelligence, agents, and new workflows are native assumptions.

The legacy model protects the present. It carries customers, revenue, compliance obligations, institutional knowledge, and cash flow. It cannot be abandoned while the future is being built.

The AI-native twin learns the future. Some work is structurally different enough that retrofitting it into the legacy model slows learning. That work belongs in the twin: agents in the workflow, different decision rights, faster learning loops, and new measures of productivity.

Two operating models, one company

The mistake is pretending one can do the other’s job. Legacy transformation protects today’s economics. The AI-native twin discovers tomorrow’s operating leverage.

Different cadence, different talent, different governance, same company. The legacy model needs reliability. The twin needs learning velocity. The leadership task is to connect them without forcing them to behave the same way.

The leadership question is capital allocation. How much goes to keeping the lights on, and how much goes to building the replacement?

Two operating models for one company are not duplication. It is a bridge. The end state is not two models forever. It is the moment when the twin has enough proof, maturity, and economic advantage to become the company.

Run the core. Build the twin. Decide, over time, which one deserves to become the company.

Posted in Uncategorized | Leave a comment

What is the demand side of AI?

AI has a supply side and a demand side. Most conversations start and finish on supply: models, tools, agents, and platforms. But capability is only half the equation. What is the demand side of AI?

This matters now because the spending is lopsided. Most budgets still pour into supply, mirroring the market’s heavy capex on AI infrastructure, while the returns stall. Get this wrong, and you keep paying for capability you never convert into outcomes.

The Demand Side of AI

The demand side is the operating model. More precisely, it is the operating discipline that decides where AI is applied, who owns the outcome, how workflows change, and how value is measured. The demand side is what makes AI operational, measurable, and productive inside the business. Without it, AI is a hammer searching blindly for nails.

Here are a few ideas to help you better shape your own demand side:

  • Adoption, not invention. The demand side concerns how organizations absorb and integrate AI into their operating models, as opposed to the supply side, which builds the models, tools, and platforms.
  • Accountability for outcomes. It centers on who owns the business result: owning the metric and setting the standard.
  • The operating model is the real bottleneck. Buying AI tools is easy; the hard part is redesigning workflows, roles, governance, data access, and decision rights so the capability actually compounds.
  • From “features” to “absorption.” It shifts the question from “what can this AI do?” to “can we convert cheap intelligence into faster delivery, better margins, and new ways of working?”
  • Supply builds intelligence; demand makes it productive. The demand side is where AI moves from being a market capability to a disciplined way of working within the enterprise.

What This Looks Like in Practice

Take a customer support team. The supply side provides them with a capable agent that can draft replies and retrieve account history.

The demand side decides everything around it. The agent now processes refunds under $50 on its own. A named person owns the CSAT score influenced by the agent. A weekly review moves more cases to the agent where it performs and pulls back the ones it should escalate.

Same model, different operating model. One team treats it as a feature and sees a demo. The other rebuilds the workflow and turns the agent into operating leverage.

The Wrap-Up

AI’s real advantage shows up on the demand side. Do not bury it under technology. Surface it as a first-class citizen. Staff it. Own it. Deliver it.

The real question is not what your AI can do. It is who on your team wakes up owning the number it is supposed to move. Name that person. Give them the authority to change the operating model. If no one owns it, you bought a capability and absorbed nothing.

Posted in Demand Side | Leave a comment

The Cost of AI just got Real

The most powerful frontier models in the world aren’t being held back by compute. They’re being stopped dead in their tracks by corporate accountants. And with good reason!

This isn’t disruption. It’s revelation. AI didn’t break corporate finance; consumption pricing always meant this. We just couldn’t see it until the bill arrived.

For thirty years, enterprise software was priced by the seat. Fixed, predictable, manageable. AI broke that contract. Frontier models charge by consumption; every token, every call, every retry. The cost is variable, and the variable is how disciplined the work is.

The taxi with the meter on tyre rotation

Imagine getting into a cab and the driver charges you based on how many times the car’s tyres rotate. If the taxi is stuck in the mud, you’re generating massive tyre-rotation costs, but you aren’t moving an inch closer to your destination. Variable price, zero progress. Now imagine the cab is your agent and the destination is the outcome you actually wanted. Where’s your return on investment?

Two layers, and a choice

First wave of AI adoption: companies bought pre-packaged meals from frontier providers such as OpenAI, Anthropic, and Google. Turnkey, expensive, microwavable. That’s the product layer. The CFO has now walked into the kitchen and said the obvious thing: we can’t run a business on microwave meals. The response is to build a commercial kitchen; model-agnostic, owned, and instrumented. That’s the substrate layer.

The product layer is rented. The substrate layer is owned. One is a recurring cost; the other is an appreciating asset.

Capture the recipe

Now, once the kitchen exists, the next move is the one most teams miss: identify the highest-value workflows, use the model to generate the deterministic recipe, then run the recipe without the model. You use the AI once. You capture the workflow. You bypass the token meter on every subsequent run.

The chef doesn’t get fired. The chef gets promoted to writing cookbooks while the line cooks run the kitchen.

This is where the operating model conversation actually happens. It’s less about whether we should adopt AI and more about which workflows are still in the kitchen with the chef and which have been cookbooked. Every recipe captured is a permanent reduction in your variable cost base.

The lights are on

The magic show is over. The blueprint and the budget sheet are on the table.

The companies that win the next 18 months won’t be the ones with the best models. Look, every CFO can buy the same model. Instead, it’ll be the ones who built their own kitchen, captured their recipes, and stopped paying rent on work that should be theirs.

So, are you still buying microwave meals, OR are you building the kitchen?

Posted in agentic | Leave a comment

Efficiency as a Growth Enabler

In transformation programmes, efficiency gains are low hanging fruit. A dirty word within today’s glorious growth agenda. But what if efficiency IS a growth enabler. What then?

Look, every time we get better at using something, we end up using more of it, not less.  It’s what consumers do.

James Watt made the steam engine more efficient, and guess what, coal use went up. We’re building faster data centres for more compute demand to keep pace with our increasing AI needs. And when electricity, the mother of all utilities got cheaper, no surprises here, we found more things to power.  It’s what we do as consumers. And those efficiency gains get swallowed up by demand growth. So what?

Well, the same thing happens inside companies. You automate a process, free up capacity, and six months later that capacity is full again. New requests. Higher expectations. A bigger backlog.

Growth Enabler

Economists call this the Jevons Paradox. But you do not need the label to recognise the pattern. Efficiency rarely reduces demand. More often, it expands it. Technologists laugh about how less is more! So what does that mean in practice?

If you are building a business case for automation on cost savings alone, you may be setting yourself up for disappointment. Costs do not always fall in the way people expect. Instead, output rises. The organisation does more. That is NOT a failure. In many cases, that is the real value. But it is a different story from the one that usually gets sold.

So a better frame is this: efficiency is not just a cost cutter. It is a growth enabler. And own it!

The real question is not, how much will we save? No, no, no! It is, what can we now do that we could not do before? Efficiency raises the ceiling.

That shift changes everything. It changes what you measure, what you promise, and what you choose to build next.

Posted in Uncategorized | Leave a comment

Change Debt

We are in a constant state of transformation: digital, operational, cultural, AI, brand. It is hitting everyone, everywhere, all at once. It is simultaneously exhilarating and exhausting.

I’ve been a technologist for the majority of my career, moving from builder to architect to leader. I never really traded one hat for another; I simply kept adding them to the rack. With every transformation, the cycle times get tighter. The “big one-and-done” transformation is a myth. Instead, we face relentless waves of change that are essential, yet leaving a wake of enterprise fatigue in their path.

Change Debt

In the software industry, we have a name for this: Tech Debt. We know how it accrues and how to mitigate it.

However, Change Debt — the residue of constant, overlapping mini-waves of transformation— is just as real and far more insidious. As we pivot to face the AI wave, we do so battered and bruised by the ghosts of transformations past.

There is a reason startups thrive while legacy organizations struggle to keep pace with innovation. It isn’t just old code; it’s Change Debt. We live in a change-or-die world, so change we must. But the debt is coming due.

That said, here are a few takeaways that require further thought:

  • Is the debt caused by the frequency of change, or the incompleteness of it? If we “think big, start small,” are we accidentally creating more debt by never finishing the small starts before the next big thing arrives?
  • If tech debt lives in the servers, does change debt live in the culture? If so, is the organization’s “operating system” running too many background processes, causing the current AI change to bring everything crashing down?
  • How do we acknowledge that the “bruising” isn’t a lack of will, but a physical limit of the enterprise? As a builder by nature, I see change as exhilarating, but for others, change often feels like instability. I’m not a doctor telling a marathon runner with a broken leg to “just keep running.” How do we give our employees the personal safety to raise that as a genuine concern?
Posted in change, AI | Leave a comment

Frequency, Duration, and Intensity: From Sprinting to Endurance in Sports and Work

When we first dive into any athletic pursuit (be it running, cycling, or even a new fitness routine), we often start by playing around with three core variables:

  • Frequency: how often we do it
  • Duration: how long we do it each session
  • Intensity: how hard we push ourselves

Early on, especially when we’re younger, we might focus heavily on intensity: short, explosive bursts that test our limits and give us quick feedback. Think about revision cramming as text before exams.

But as we mature (both in sports and in our professional lives), there’s a shift. We start valuing frequency and duration more. We unlock endurance. Instead of going all out in a single sprint, we learn the importance of pacing ourselves. We focus on doing something consistently, for longer periods, and building  that endurance. This approach doesn’t just lead to safer, more sustainable progress in sports; it also mirrors how we might evolve in our careers.

In the workplace, the young professional might tackle projects with high intensity: pulling long hours and sprinting through tasks. But with experience, we understand that frequency (showing up reliably) and duration (putting in steady, sustained effort) matter more for long-term success. Just like a marathon, maturity in work and life is about endurance rather than raw speed.

Data. Operations. Talent. Software, or DOTS.  Their digital transformations within organizations and across enterprise require endurance programs over explosive projects.  Favoring horizontal change over vertical inertia. 

So, whether you’re lacing up your running shoes or stepping into a new role, think about shifting from that initial intense sprint to a more measured, frequent, and enduring pace. It’s not just about lasting longer; it’s about performing smarter in the long run. Slow and steady wins the race!

And yes, we’re all getting older…

Posted in transformation, change, work | Leave a comment

From GenAI to Agentic AI: Reconnecting the DOTS for Real ROI

One of the most pressing concerns with Generative AI (GenAI) today is the perceived lack of return on investment. Many organizations are struggling to translate AI hype into tangible value. But the problem isn’t with the technology, it’s with the readiness of the organizations attempting to adopt it.

Most enterprises simply aren’t AI ready. Their processes are fragmented, governance is inconsistent, and integration strategies are underdeveloped. Without these foundational elements in place, AI efforts stall, delivering limited business value.

To change this, we need to shift our focus from GenAI to Agentic AI.

Agentic AI: The Real Opportunity

GenAI was the warm-up. It showed us what’s possible with content creation and automation. But the main event is Agentic AI, autonomous, goal-oriented systems that can make decisions, take action, and collaborate effectively alongside human teams. Agentic AI isn’t just about generating content. It’s about augmenting human capability and driving business outcomes.

This evolution demands that we rethink how work gets done and redefine the role of the human workforce. We’re moving from humans using tools to humans working with agents.

Reconnecting the DOTS: A Holistic Approach

To realize the full potential of Agentic AI, organizations need to reconnect the DOTS: Data, Operations, Talent, and Software.

  • Data must be restructured to feed intelligent agents with quality, context-rich information.
  • Operations need to be reengineered to accommodate new workflows where human and agentic systems collaborate.
  • Talent must be reskilled to work with, manage, and supervise AI agents.
  • Software architecture must be rethought to enable interoperability, agility, and continuous learning.

This is not a quick fix. Reconnecting the DOTS is a long-term commitment. It’s hard, often thankless work that must span across lines of business, not just isolated digital functions. But it’s essential, both for immediate gains and sustainable transformation.

The ROI of AI Starts with Readiness

The business case for AI becomes clear when Agentic AI is in place and the DOTS are aligned. Until then, expecting ROI from GenAI alone is like expecting enterprise transformation from a chatbot. GenAI may have lit the spark, but Agentic AI is what will power the engine.

Now is the time to move beyond experiments and proofs of concept. It’s time to get serious about AI readiness. That means making the hard changes, starting with reconnecting the DOTS.

Posted in Uncategorized | 1 Comment

MCP Servers: Giving LLMs Hands to Act

Dinner Talk & The Talent Crunch  

My wife and I had dinner last night with a Seattle‑based engineering couple.
The husband was laid off in January; the wife voluntarily left her role soon after.
Both landed new jobs—but only because they could prove they’d create value on Day One. The market is flooded with strong résumés; what companies crave is demonstrable expertise.

Fast‑forward to an Anthropic conference in San Francisco. When a room of 275 engineers was asked, “Who here has built an MCP Server?” every hand went up. “A remote MCP Server?”—almost every hand stayed raised. Clearly, knowing MCP is fast becoming table‑stakes.

So… what is an MCP Server, and why does it matter?


Why LLMs Need Hands

The Lonely LLM

Large Language Models are wonderfully chatty—but all mouth, no action.

“Send an email.” —Sure, they’ll draft it, but they can’t actually press Send.
“Book me a doctor’s appointment.”—They’ll explain how, yet never pick up the phone.

The Handy LLM

Early fixes bolted one‑off “hands” onto the model: custom code to hit Gmail’s API, Instagram’s API, DoorDash’s API, and so on. Every new action meant wiring up another bespoke integration.

The result? A brittle monster that’s impossible to maintain.


Enter MCP: One Language, Endless Actions

MCP (Machine Control Protocol) normalises the chaos in two key ways:

  1. Shared language – All hands speak the same, JSON‑based dialect (think of it as everyone agreeing to conduct business in English).
  2. Provider‑owned hands – Each service vendor ships its own MCP Server, so you don’t own the integration burden.
MCP TermReal‑World Analogy
MCP ClientYour LLM‑powered app (the “brain”)
MCP ServerA detachable hand built by, say, Gmail or Notion
MCP ProtocolThe common language that brain ↔︎ hand both understand
The MagicGlove LLM

With that glove‑and‑hand abstraction, an LLM can now:

  • Send an email (Gmail MCP Server)
  • Post to Instagram (Meta MCP Server)
  • Order pizza (DoorDash MCP Server)

All by speaking plain English.


2025 Outlook: A Cambrian Explosion of Servers

Expect 2025 to feel like the early days of mobile app stores—but for actions instead of apps. Every SaaS vendor wants to be “MCP‑enabled” so the next generation of agentic products can wield its service with zero friction.

  • Acceleration loops – As more servers appear, building agentic apps gets simpler, which attracts more builders, which motivates more servers…
  • Commoditised integrations – Hand‑rolling APIs will quickly feel as dated as dial‑up modems.

Why Non‑Techies Should Care

If you can describe a task in English, you can now automate it:

“Email the team my weekly update, post the highlights to LinkedIn, and text me when it’s done.”

MCP shifts the bottleneck from coding skills to clear intent. Business builders—from product managers to HR partners—gain superpowers without touching a line of imperative code.


Key Takeaways

  1. Expertise beats experience. Hiring managers want people who already know today’s critical tools—MCP is rapidly joining that list.
  2. LLMs + MCP = action. Generative models become operative models when equipped with MCP “hands.”
  3. The next platform play. Just as HTTP unlocked the Web, MCP aims to unlock autonomous agents.

Ready to slip on the magic glove? 2025 is your year.

Posted in agentic, AI, automation | 1 Comment

The Agentic Slider: Reflections from Karpathy’s Keynote

I really enjoyed Andrej Karpathy’s keynote at AI Startup School in San Francisco. As the former Director of AI at Tesla, Andrej is both smart and articulate. His talk got me thinking—again—about agentic modes of work, especially the idea of the agentic slider, which I’ll unpack here.

Agentic Modes of Work

We are shifting—slowly but surely—from the left column to the right. And contrary to popular opinion, I agree with Andrej: this isn’t the year of agents. It’s the decade of agents. It’s going to take longer than most people think, because people are involved.

The Agentic Slider

Let’s use Andrej’s Iron Man analogy. Right now, we’re just starting to suit up. We’re augmented—with a few nifty gadgets at our disposal—but still firmly in control. We’re the human boss.

As the suit gets smarter and more capable, the dynamic shifts. We move from being the driver to the passenger. The system becomes orchestrated. We’re still in the loop, but now we’re more contributor than controller.

Eventually, the Iron Man suit flies on its own—automated. That’s the far end of the agentic slider. But we’re not there yet. Today, we’ve got employees walking corporate corridors trying to right-size themselves into Iron Man suits.

This is the agentic slider in action: from augmented → orchestrated → automated.

But here’s the catch: this shift doesn’t happen in neat, sequential steps. It’s not a smooth handover of control. Why? Because humans still need to verify everything agents generate. And that makes us the bottleneck.

It’s a necessary bottleneck—for now. Which is why we need better GUIs. Interfaces that help us audit AI. Tools that keep agents on a tight leash. Otherwise, it’s garbage in… and even more garbage out.

Moving the agentic slider to the right requires maturity—earned through real-world experience. That maturity comes from:

  • Building GUIs that reduce human bottlenecks,
  • Shortening the distance between generated and verified,
  • And crafting agent experiences that are AI-ready and optimized for high-automation environments.

We’re not flying yet. But the suits are getting smarter. It’s time to design the systems—technical and human—that will get us off the ground.

Posted in AI, automation, agentic | Leave a comment