New month, new state-of-the-art. GPT-6 Astra leads the pack. Ox Alpha caused a stir as an anonymous model with no vendor that was crushing benchmarks - then turned out to be Z.ai’s GLM-5.3-Flash (open weights now released).

But let’s turn our gaze to the physical world. It has been an equally exciting month down there.

OpenAI showed off Jalapeño at Hot Chips - their own inference chip, which is the infrastructure we’re paying for when we buy tokens. Google, Amazon and Microsoft already have their own. Anthropic has confirmed it's starting. Independent vendors like Cerebras are already selling. Spicy indeed.

Apple stumbled into the same inference argument almost by mistake. A few months ago, everyone went crazy for the Mac Mini - it has now refreshed the Mac Studio, and given it pretty mental AI processing capabilities.

But it’s expensive. I priced up the top spec - a mere S$27k. Should I add AppleCare+? Seems important 😉

Not that you can actually buy one. The waitlist is months long - OpenAI alone allegedly bought tens of thousands.

Scaling up from the silicon: at the World Humanoid Robot Games in Beijing, an X-Humanoid robot ran the 100m in 8.86 seconds and cleared 2.88m in the high jump, both beating human world records. The long jump is still ours - for how long? I highly recommend watching the failure reel: ABSOLUTE CINEMA.

Closer to the home lab, Hugging Face is selling the “Microduck” for $399 - a 25cm biped, 15 motors, camera, LiDAR, and the whole AI software stack open on GitHub. Train a behaviour like dancing or following in simulation, then deploy it to the duck. Marvellous.

Its siblings sit in the same bracket. Reachy Mini from $399. Petoi's Bittle from $269. LeRobot's SO-101 arm from about $100 if you print the parts yourself. A walking biped now costs less than a phone.

Maybe that’s the next MISSION+ space - a bar for people to watch robot sports, tinker with robot kits and eat pizza. Maybe I’ve just found my retirement plan!

Reflections On The Mission

Spec Driven Development was the first unlock for agentic engineering, but other best practices are now entering maturity.

We are shifting to remote agents. The moment agents were running from a command line, remote execution was inevitable. We all work across multiple computers - including our phones! - so it’s the difference between editing a local document and collaborating on the version in the cloud.

Remote agents also make parallelism easier, plus coding agent hand-offs: one agent writes the code, another verifies - communicating via a shared document or message queue such as the GitHub PR.

Running multiple remote agents requires a centralised operating interface. Whether this is Vibe Kanban, herdr or just integrated with Jira - it needs to come together somewhere.

The ‘shape’ of agentic skills has settled. We’ve transitioned from holistic, methodology-shaped approaches (the BMAD method with its agent personas, Superpowers with its enforced flow) to individual task-based packs (Matt Pocock’s skills, Poteto’s pstack) where you might only use one or two.

Repo-level specifications are great for describing functionality within that repository's scope. But not all specifications work this way - sometimes an application is made up of multiple repositories; sometimes specifications are mandated across multiple applications.

For formal, versioned specifications, an approach like OpenSpec’s “Stores” makes sense - these exist in their own repository and are resolved by OpenSpec on demand. Other parts of the specification probably work better by being pulled in from Confluence or Notion - brand guidelines being the obvious example.

AI is for reasoning, discovery & analysis. Not for burning through tokens for the same intelligence over and over again. Yet that’s what we seem to keep doing. Instead, we should move repetitive tasks to deterministic scripts, and have AI handle failures or analyse abnormalities. Agentic testing becomes Playwright automation plus AI error triage.

Put all this together, and our applications are becoming ‘evergreen’ - paying off technical debt as it arises. The evergreen application is tied to an agent that periodically bumps framework & library versions, scans through error logs & bug reports, executes vulnerability and penetration testing, trawls customer feedback on the App Store or Trustpilot - then fixes and verifies any issues.

The Agent Centric Development Cycle (ACDC 🤘) is maturing, and I love it.

Interesting Links

• MAS to invest S$220 million in fintech innovation, targets frontier tech and talent - great to see this program renewed, Singapore leads the way!

• Black Hat USA 2026 | The 'Breaking' News: The OpenAI–Hugging Face Incident - yeah so this isn’t terrifying at all.

• Novice Mount Shasta climbers rescued after relying on Gemini AI to plan trip - so much to unpack here. “Although the climbers said they did not feel well, they pushed forward.” I love the enthusiasm. This is up there with “GPS told me to drive into the lake”.

This Is The Way

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

The fight for the naughtiest model is on!

OpenAI hacked Hugging Face. Anthropic couldn’t stand losing the most dangerous model high ground, so announced that they had in fact participated in not one, but three near felonies.

Responding with the confident scoff of a career criminal, OpenAI announced that actually they had hacked another four companies, not just Hugging Face. And so on, and so.

Enter Felony Bench. The only benchmark that matters right now.

I’ve always said that Google was the stalking horse of this race. They have the physical infrastructure, the chips, the data, the distribution - what else could they need? They even have Demis Hassabis and DeepMind - the best lab!

Oh wait, Demis has been moved to Chairman and Jeff Dean has left. This has been spun as a positive move, but it’s hard to see it that way.

Or maybe they had to go because of poor performance on Felony Bench? Gemini just wasn’t naughty enough.

Reflections On The Mission

MISSION+ is a believer in Spec Driven Development. It’s the primary difference between agentic engineering and vibe coding. A coding agent will always generate code, the spec maximises the probability that what it produces is what we actually want.

"Spec" here is wider than the word usually implies: not just functional requirements, but non-functional requirements, security guidelines, architectural constraints, UI and UX, data structure, and the methods by which we verify that what got built is actually correct.

Meanwhile, the talk of the town is to “shift left” - blur the lines. AI helps business people ship software, developers create UI designs, and product managers write the acceptance tests. During exploration, there is no argument here; a rough prototype is the best way to resolve the very ambiguities that make specification writing hard in the first place.

But blurred boundaries are a recipe for disaster in any organisation beyond the earliest of startups - not because broad collaboration is bad, but because ‘hard’ decisions stop being made. When everyone can edit the security section, nobody is ultimately responsible for it, and the agent progresses regardless.

Authorship can be radically distributed: a product manager armed with AI can draft an architecture section. Accountability cannot. And some sections - like security - probably need to be locked down from keystroke one.

The accountable owner is the person with the authority to resolve conflict inside the artifact, and who answers for the outcome.

Every artifact in the specification needs a name against it:

• Functional Requirements -> Product Owner

• Performance & Non-Functional Requirements -> Product Owner

• Data Model & Migrations -> Data Owner

• Acceptance Criteria & Verification -> QA Lead

• Solution Architecture -> Engineering Pod Senior

• Enterprise Architecture -> Chief Architect

• UI Design -> Product Design Lead

• Brand Look & Feel -> Organisation Design Lead

• Product Security Requirements -> Engineering Pod Senior

• Organisational Security Guardrails -> CISO

• Regulatory & Compliance Constraints -> Head of Compliance

Some of these are per-project, like Functional Requirements. Others are organisation-wide, or at least department-wide - the regulatory & compliance constraints to which we must adhere don’t change with every sprint.

And these sections can contradict each other, because we operate in a complex world. The security guardrail forbids PII in application logs; the observability requirement wants full request payloads for diagnostics. Both artifacts have owners, both owners are right within their scope, and the agent will just quietly pick without telling you. The senior agent orchestrator needs to resolve this kind of ambiguity upfront, it’s now part of our job.

Operationalising these artifacts is its own emerging craft. A security policy sitting in a 200 page PDF in a shared drive somewhere is not an actionable agentic guardrail. It needs to be made easily accessible to agents as part of the initial harness setup, and updated as it changes.

The payoff is audit and responsibility. When agents generate code, it’s hard to read every line and attribute each back to who wanted what. But having the agent generate a change summary that attributes intent - and the part of the spec it came from - is absolutely possible. And that’s what the auditor really wants. Plus it stops endless application updates between competing views, like some out-of-control wiki edit war.

Blur the work. Don't blur the accountability.

Together, We Build {+}

Interesting Links

This month’s Interesting Links is all themed around resources that anyone can use with their coding agents to produce beautiful designs and impactful interfaces.

• Canvas UI - An open source library of some pretty spectacular web effects. WebGL is very powerful, although Spiderman would probably have some advice about over-using some of these…

• Happy Hues - Colour combinations that work, and breathe a bit of originality into your designs. I’m looking at you, Claude Purple.

• Diagram Design - Agent skills to create 29 diagram types in HTML that look neat and professional. For websites or presentations.

• Thinking Orbs - Now that our apps ‘think’, we have adopted a new visual language to reflect that. This is an open source collection of orbs that pulse and gyrate as smoothly as me on the dance floor 20 years ago.

• DesEngs - Billed as “The Ultimate Resource for Design Engineers”, this site collects and publishes resources to help us become better design engineers - an emerging discipline that blurs design & engineering, producing visually compelling components that go beyond Figma.

This Is The Way

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Fable is back. ‘Twas but a blip.

Cue lots of conversation about model capability, what we consider ‘safe’ to release, and the potential futility of trying to control things as open weight models catch up.

Whilst interesting, that misses the bigger point and the thing enterprise should be actively discussing right now: can we trust American technology to not get yanked away without warning?

Sure Fable was in beta, so the blip didn’t truly impact us very much. But what if there were significant production workloads? And this isn’t really an AI problem, it’s true of any technology.

Anyone who has worked in a regulated industry has always had to carefully consider Disaster Recovery (DR) and Business Continuity Planning (BCP). If a service or vendor goes out of business or is unavailable, what’s the plan? For example, under the EU's DORA and the UK's operational resilience rules, financial firms must not only plan for an outage but also document and test a viable exit strategy for every critical third-party provider.

One option is to adopt the so-called “East-West” strategy. The US isn’t the only game in town, so enterprises can mirror their Western vendors with Chinese counterparts. A pity there aren’t more viable options right now, but I’m sure they’ll come one day.

The East-West strategy is a good one, but doesn’t guarantee anything. Beijing is also looking at curbing overseas access to China’s top AI models, and there has always been persistent doubt around using Chinese infrastructure (whether valid or not).

Is a shift to self-owned technology inevitable? Anti-cloud advocates have long said “There is no cloud, it's just someone else's computer.” Does this all result in privately hosting AI models - potentially compromising capability against continuity?

Literally hosting models is complicated and requires up-front infrastructure investment, but might make sense for some. For others, using an in-country provider might make more sense. Much of AI processing is transient compute. Using stateless model providers would allow us to route to wherever there is capacity. There is a huge opportunity here for the neo-clouds, or even the traditional players like AWS (particularly through their partnership with Cerebras).

The space is maturing fast, the risks are only beginning to be understood. We’re just getting started!

Reflections On The Mission

What parts of “programming” are still worth learning as a beginner? What is still useful, nay, necessary in order to be effective in a world where agents can generate the code?

As I was pondering this question, I had a bit of an epiphany. There is a clear correlation between the topics we need to learn, and those that are still useful to put into documentation - or even an agentic specification. Those are the bits that humans read, so clearly the bits we need to understand!

Deepwiki produces detailed documentation on a source repo. This is free for public repositories, or part of Devin for private ones. What it chooses to catalogue is essentially a guide to what a beginner should learn.

What does that look like? Obviously the architecture - the result of thinking in clear abstraction layers. Although I’m not sure how one learns that, which is maybe a topic for another time. Struggling students have often despaired to me that they can clearly see the outcome they want - they just can’t see the path to get there. My advice has always been to break the big problem into smaller, but still significant, steps, and then break them up - and so on.

At the other end of the spectrum - memorising syntax is probably a waste of time for many. No need for that to be in the docs!

What are the topics in between these two extremes? Performance scaling methods seem important, if only to make sure they’re not applied too early by an overly eager AI agent. Testing & verification, along with governed deployment mechanisms, is more important than ever.

At least for now, how to structure data and databases is still necessary. Source code is stateless, and agents are great at refactoring it. Not always the case for stateful data, and the associated migrations that are sometimes needed.

Beyond the documentation, a deep understanding of security principles is a must. The security strategy is often not part of documentation, but it can’t be forgotten! As my friends at AWS often say, "Security is Job Zero".

But other than that, my advice to beginners looking to go deeper would be to just start reading through the Deepwiki entry for an open source project that interests you, and use your favourite AI to explain any of the terminology you don’t understand!

Interesting Links

• Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402 - interesting use case for stable coins.

• How Google SRE is using agentic AI to improve operations - we’ve all been quite focused on agentic build, but the run/ops side of things is equally important! MISSION+ will be publishing more on this topic soon.

• The 2026 AI Engineering Report - a VC-published survey of over 1000 engineers on their usage of AI engineering.

This Is The Way

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Why do teams that adopt agentic engineering still end up with broken code nobody can explain?

Is it the models they're using? The way they're prompting?

In this article, Jelmer Cormont, Fractional CTO at MISSION+, argues that it’s something happening underneath the output that most teams never stop to examine.

If you work with AI coding agents or are thinking about how to introduce them properly to your engineering workflow, this insightful article breaks down what is actually happening and how to work with them.

Read the full piece to see where agents earn your trust, and where handing them the wrong work leaves you with code no one can explain.

Over the last month, we’ve had lots of conversations with companies about their agentic engineering strategy. It’s clear that this has now entered the mainstream. The time for experiments and pilots is over.

To share some themes: the conversation has shifted from “is this even possible” to “how do I do this safely, without blowing the budget”. Whether it's achievable barely comes up anymore - it's taken as given.

The number one topic is token spend. For a short period of time, “tokenmaxxing” was worn as a badge of honour: “Look mum, I managed to spend $12,514 in tokens this month!”. Leaderboards were created to celebrate those who had spent the most.

This was, of course, ridiculous. Goodhart’s Law obviously applies, but even without that - rewarding effort and not outcomes is always a dangerous path. I can use more words than the next person - it doesn’t mean I’m right (much to my disappointment).

Ideally, we would be able to tie business outcomes - or at least productivity - to the AI spend. I expect this to become a core ask from management. Tooling and observability will need to evolve to match that demand.

In the meantime, here are some quick wins:

• Plan before you build. The plan is the map, not the territory. Use Plan Mode and Spec-Driven Development - agreeing a plan before you touch code. It's not just the ~50% token saving on reasoning-heavy work; a clear plan stops expensive vibe coding.

• Right-size the model. Default to a cheaper model like Sonnet, dropping to innovative open weight models for simple tasks - reserving the frontier models for genuinely hard problems. The cost difference isn't only around intelligence: models differ in how much code they emit for the same task, the tighter the model the better.

• Compact and clear deliberately. Run /compact at logical breakpoints and /clear between unrelated tasks so you're not dragging stale context (and its token cost) from one job into the next.

• Trim the context you carry into every prompt. Disable MCP servers you aren't using - each loads its full tool schema into every call (500–2,000 tokens), so a couple of idle ones quietly eat 5–10% of your window. (A .claudeignore helps here too in big repos, but it's a minor lever). Use markdown scratchpads for memory.

• Audit, don't guess. Use /context and /cost to see where tokens actually go, so spend tracks to work done rather than session length.

This stuff isn’t easy. Reach out to MISSION+ for specialist help.

Reflections On The Mission

When we ask a coding agent to start building, it will always generate something. Whether or not what is produced is what you actually intended is a different question.

Agentic engineering is essentially increasing the probability that what is produced is what you intended:

• Want to increase the probability it has the correct functionality? Ensure that functionality is well-specified with verification criteria.

• Want to increase the probability it matches your coding standards and quality gates? Ensure those standards are included in the specification.

• Want to increase the probability it aligns with your architecture, and doesn’t try to reinvent the wheel for existing services or components? You’ve guessed it - ensure the architecture diagrams and service descriptions are made available to the agents.

Imagine an application that needs to send a notification email or SMS, depending on user preferences. The agent will very happily start building an entire notification infrastructure from first principles if it thinks that is what is intended. 

We can draw upon Andrej Karpathy’s analogy that LLMs are a new type of computer, and the contents of the context window are the programming language (Software 3.0 in his words). We add detailed specifications to ‘program’ the LLM into doing the correct thing.

A common use case for agentic engineering is an automated code migration. When we’re just bumping from version x to x+1, the agent will probably do the right thing. But if we’re trying to migrate from e.g. Delphi or PowerBuilder to a modern React application, things are more complicated.

The naive approach would be to just ask agents to examine the existing code and migrate. The issue with this is that the ‘programming’ for the LLM contains all sorts of legacy implementation details that will poison the context of the agent doing the heavy lifting.

Working, production code is, by definition, a perfect specification of what the application does - albeit in a formal language that is unnatural to us. We can use this code to extract a very detailed specification of expected behaviour, without copying implementation details. This can then become the basis for our migration agent, with the legacy code used to triangulate and verify success.

We’re only just scratching the surface of what Software 3.0 looks like, and it’s an exciting time to be an engineer, figuring this all out together.

Interesting Links

• Instagram Meta AI Vulnerability: How Hackers Bypassed 2FA with Prompt Injection - how the recent Instagram hack was carried out. Spoiler: it’s not complicated, and shows the very real risk of deceiving an AI with elevated permissions to carry out a compromised action.

• NVIDIA CEO Begs Execs to Stop Telling Workers They're Fired Because of AI - Jensen is correct, right now it’s a convenient excuse to correct for previous overhiring. But this will not be true forever…

• Anthropic Coding Workshops - material from Anthropic with hands-on workshops to become better at using Claude.

• The Tests We Skipped - neat article from local legend Ajey Gore. Totally agree that the current PR theatre is going to be an early casualty of the shift to agentic engineering (although we still need some kind of hook to trigger our security and code quality scans).

• Rewiring finance for AI, with Ned Lowe - some interesting points on agentic engineering, if I may say so myself!

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Within a single week we got Qwen 3.6, Kimi K2.6, and DeepSeek V4. Well, GPT 5.5 and Opus 4.7 also dropped in that same window - but our story isn't about them.

The frontier no longer exclusively belongs to the most well-funded labs. The gap between the leading open-weight Chinese models and their closed-source American cousins on benchmarks like multi-step task completion, tool call accuracy, and agentic coding tasks has shrunk to low single digits. Close enough to practically call it a tie for most of the engineering work most of us do. And these things run on hardware at roughly an order of magnitude lower cost than the US frontier APIs. That shifts some of our thinking away from ‘can we achieve this outcome’ to ‘how cheaply can we achieve this outcome’.

Slightly earlier in the month we got Google’s Gemma 4. This is small enough to run on an iPhone. Not "running on your beefy M3 Mac" or massive Nvidia GPU... On your phone. Honestly, I’m still a little in disbelief on this - as are people I demo it to, who pretty much every time ask “where is it getting the data from?” when I turn on airplane mode.

Sure, the smallest variant isn't going to one-shot a refactor of your ancient code base, but it'll handle local summarisation, classification and tool routing without ever touching a network. And the larger, but still locally running, version will happily allow you to code on an airplane (actually let’s not do that, that is a sacred space). Whole categories of "ship the user's data to a third party" architecture just became unnecessary, and a bunch of privacy-minded individuals breathed a huge sigh of relief.

OpenAI quietly released Privacy Filter - an open-weight PII masking model under Apache 2.0. 1.5B params total, only 50M active thanks to its Mixture of Experts architecture. WebGPU, transformers.js, weights cached in IndexedDB - it runs in your browser! This is the new pattern: small specialist models sit at the edge, sanitise the inputs, and only then hand off to the big hosted model. Defence in depth, locally.

I couldn't help but notice the launch of USVC - a new closed-end fund chaired by Naval himself, giving retail investors exposure to OpenAI, Anthropic and xAI from $500. Patriotically named, but at least a 3.61% gross expense ratio and "highly illiquid" (their words not mine), combined with a structure that sidesteps accredited-investor rules. Is this the savvy democratisation of Silicon Valley, or a beautifully-orchestrated way to offload paper from the private investor to the retail punter? Calling the top of the valuation of the private labs? Maybe - let's check back in later this year.

Reflections On The Mission

In Spec Driven Development, we write detailed specifications to maximise the probability that a coding agent produces the outcome we actually want. Some have taken this to an extreme conclusion: the spec becomes the new source code, and the actual code is just a disposable derivative like the compiled binary. Delete it, regenerate it, ship it. Specs all the way down.

There's a problem with this line of thinking though. The spec → source process is probabilistic. The source → binary process is deterministic. So every regen produces a slightly different codebase: a different choice of error string here, a different stacking order there, a subtly different SQL query in a place that maybe shouldn't matter… But it does.

To stop the non-deterministic drift, you'd have to pin every variant down inside the spec. The exact wording of every toast message. The exact tab order of every form. The exact retry policy for every failed call. My brother, what do you think source code is? It's a precise specification, written in formal language, that a deterministic compiler can interpret without ambiguity. We invented this for a reason. Yeah ok the syntax is ‘uglier’ than English, but that's a feature, not a bug.

So the interesting question isn't "spec versus code." It's "where in the stack do I stop being human-friendly and start being machine-precise?" High-level intent (“users can recover their account if they lose their password”). The exact regex that validates the email field? That's source code. Dressing it up in markdown bullets won't help anyone. If you find your spec creeping towards literal assertions about pixel offsets and timeout values, you haven't replaced source code. You've reinvented it, in a slower, fuzzier dialect.

Deepwiki, from the Cognition crew behind Devin, is a revealing insight into this. Swap github.com for deepwiki.com on any public repo and you get an AI-generated wiki, with architecture diagrams, module-level explanations, dependency maps and a chat assistant, all grounded in the actual code. It automatically regenerates as the code changes. It walks the fine line between a form of spec and code - it is detailed enough that a reader fully understands the application, but it doesn’t expose actual implementation details. An actual spec would spend more time talking about intent and less about architecture, but the point stands. This is the level of agent-assisted detail we should be aiming for in the future.

Interesting Articles

• LLM Leaderboard for Code Quality & Security - our friends at Sonar compare different models for things like number of lines of code to pass challenges, and coding issue density. Just ‘passing a test’ isn’t enough - how you pass it is important!

• NanoClaw — Personal Claude Assistant (second brain for a diplomat) - Vivian Balakrishnan is Singapore’s Minister of Foreign Affairs. And apparently he has also succumbed to the desire to run a Claw.

• Commentary: Anthropic’s ‘too dangerous to release’ Mythos AI model is a wake-up call for everyone - some of the “omgz this is just too dangerous” language is marketing rhetoric, but the fundamental idea that AI-augmented vulnerability scanning is now a part of life is all too real. Time to shift to AI-augmented defence and pen testing.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

As I've been doing more and more agentic engineering, I'm increasingly "letting go" and letting the agent make decisions. This increases velocity dramatically, but obviously introduces a whole new set of questions. How do I know the code is fit for purpose? How do I enforce quality? Are there any security concerns?

I have been perfecting two frameworks that try to address this:

• The Agent-Centric Development Cycle (ACDC) - how to transform the development lifecycle given the capabilities of AI agents

• The Agentic engineering Target Operating Model (ATOM) - how to transform the tech organisation given the introduction of ACDC

The two groupings of approach are "preventative" and "corrective".

Preventative

The more detailed the specification given to your agent, the more likely it is to produce the results you intended. This is precisely the opposite of "vibe" coding, where you just iteratively go with the flow. Instead, "Spec Driven Development" is all about structuring your product idea as clearly as possible, letting the agent do its thing, then verifying the results. Improvements and clarifications are fed back into the spec, and the process reruns.

The preventative controls are the instructions that live within your markdown files and tell your agents what to do.

Corrective

Agentic harnesses now have the ability to automatically spin up your code and test it against your specification. Claude Code, Codex and Cursor can all run your application, execute your test suite and verify that the output matches intent - without you lifting a finger. This is a massive shift. The agent writes the code, then validates the code. Done.

Cross-model verification takes this a step further. OpenAI recently released an official Codex plugin for Claude Code that lets you use the Claude model to write the code and a completely different OpenAI model to review it. A single model reviewing its own work is like marking your own homework. A second model from a second provider introduces genuine adversarial tension - it has different training, different biases, different blind spots. A multi-agent review loop that is far harder to fool with sycophancy.

Finally there's SonarQube, which now auto-detects AI-generated code and applies targeted security and quality scanning. Sonar reports that 42% of all committed code is now AI-generated or assisted. External scanning tools like Sonar act as an independent quality gate: they don't care who or what wrote the code, they just tell you if it's any good.

Insurance

I have a theory that insurance may enter the game. We already have Errors & Omissions (E&O) insurance that protects businesses against claims of mistakes or negligence. This concept could be extended to code that has been generated by AI agents.

But insurers aren't going to underwrite any old vibe coder. In a similar way to how they use frameworks and attack surface to evaluate cyberrisk, they would need to see evidence of a systematic, structured approach to agentic engineering. Where are the guardrails, where are the verification gates, where are the sign-offs?

Mosaic x aiSure (specialist AI E&O underwriting backed by Munich Re) is the first offering I've seen which is approximately what I am describing, although for AI more generally rather than specifically for agentic engineering. But the basic concept is the same.

And wouldn't you, the customer, prefer to know that the software you were buying or consuming had been evaluated and backed by an insurer with money on the line? I know I would.

So yeah, let's stop mixing up vibe coding with something that is infinitely more structured.

Reflections On The Mission

The Luddites were very scared of the impact of technology on their way of life. They were textile workers in early 19th century England - skilled craftsmen who had spent years mastering their trade. The introduction of power looms and stocking frames threatened to make them obsolete overnight. So what did they do?

Out they came, and smashed the machinery. Organised raids, hammers swinging, frames splintering. They even had a name for their favourite sledgehammer: "Great Enoch", after the ironmonger Enoch Taylor who had built the very machines they were destroying. Poetic.

Nowadays, we laugh about the Luddites - it has even become a form of abuse, a pejorative. "Haha, you don't even know about the three seashells you Luddite!" Hilarious.

They were correct, but only in the short term. The impact was devastating: wages collapsed, skilled roles vanished, and those who resisted were met with mass arrests, public hangings, and penal transportation to Australia. The government deployed more troops against the Luddites than Wellington had taken to fight Napoleon in the Peninsular War.

If you were to take a Luddite and show them the quality of life of the average English citizen today, they wouldn't believe their eyes. The quality of food, of medicine, of leisure time would be kingly by Regency-era standards.

Someone joked to me about how in the future, perhaps we wouldn't have to do our own laundry. My friend - we already don't do our own laundry! Tell your great grandmother about how hard it is that you are forced to pick up a pile of dirty clothes, put it in a magic box, then take it out a couple of hours later and it's clean. Doing your own laundry involves a mangle and a beating stick.

Correct in the short term, fantastically wrong in the long term.

I like to think we're at a similar tipping point. Many people - including myself on dark days - lament about the end of jobs, the end of career progression, even the end of society. It's different this time, they say.

It's probably not. It's easy, nay lazy, to write off human adaptability and assume the worst. If we allow ourselves to dream then future generations will have access to medical care, education and nutrition that would be as kingly as the Luddite comparison suggests.

Nobody told the Luddite's grandchildren to become railway engineers. Nobody handed them a career brochure for "telegraph operator" or "factory inspector." Those jobs didn't exist yet. They couldn't exist yet - not until the world had finished rearranging itself around the new reality. The roles that will define the next fifty years of human work are, by definition, ones we cannot currently name.

The future is not today minus something. It's something else entirely. Something that will feel, to the people living in it, completely obvious and unremarkable.

Will the transition be painful? Obviously - it always is. The Luddites weren't wrong to be angry, and you're not wrong to be worried. The people who get hurt during these shifts are real people with real mortgages, and "it'll be fine in a hundred years" is cold comfort when you can't make rent in March.

But the destination? The destination is extraordinary.

Your great-grandchildren will look back at us, sitting in our ergonomic chairs, hand-crafting code letter by letter, eight hours a day, five days a week…  and they will feel the same tender disbelief you feel when you imagine your great-grandmother beating shirts against a rock.

You did that? Every day? By choice?

Not by choice. We just hadn't built your world yet. Be optimistic, it’s worked every other time up to now.

Interesting Articles

• Shannon - An AI based autonomous, white-box AI pentester for web applications and APIs. 

• I was a 10x engineer. Now I'm useless - thoughtful reflections on life as an engineer post agentic-engineering 

• Claude Code for Everyone - Claude Code is not just for engineers. Everyone should pass this course as a rite of passage when becoming a man (or woman).

• Paperclip: Open-source orchestration for zero-human companies - this is either the future or a massive boondoggle. Would love to get feedback from people who have tried it in real scenarios.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Most organisations invest in AI tools with high expectations, then struggle to turn early wins into lasting change.

The issue is rarely the technology. It is how people, roles, and workflows adapt around it.

In this article, Matthew Choo, Head of Artificial Intelligence at MISSION+, shares four hard-earned lessons from driving AI adoption across real organisations. From behaviour change and rewiring to moving beyond prompts and putting teams into practice mode, the piece breaks down what actually accelerates agent adoption.

If your AI initiatives show promise but momentum feels hard to sustain, this article explains why and what to do next.

Read the full piece to learn how organisations move from experimentation to compounding impact.

When someone wants to remember an open source project that is hosted on GitHub (the main open source code hosting provider), they can click a small yellow star to add it to their list of projects. The number of stars is often used as a proxy for how popular a project is.

OpenClaw is an AI personal assistant that took the world by storm. Its takeoff of GitHub stars is perpendicular. 

Why? For many people, this was the first glimpse into an autonomous assistant that could help them day to day. But again, why OpenClaw and not any of the attempts that came before?

To me, the answer lies in the complaints about OpenClaw security that soon emerged. “What? You gave it complete access to your email?”. “What? It can us` your stored browser credit cards without constraint?”

But these questions got it wrong. From the perspective of the user, this was not a security vulnerability - it was a feature.

Users liked that it had access to everything, that was what provided them value. To “correctly” lock it down would remove much of the reason they were using it in the first place.

I don’t have the answer, but I recognise that saying “agents can’t have access to potentially sensitive parts of my life” is about as useful as preaching abstinence to teenagers. An approach that acknowledges the benefits, but encourages protection is the more pragmatic option.

This overlaps with our transition to a post-privacy society. As Peter Diamandis has frequently said, “Privacy is Dead”. Most of us accept that Google reads our emails, tracks our searches and follows our location on Maps - because, like OpenClaw, we trade risk for convenience.

The questions about personal data security and privacy were always present, but the emergence of workable agents has thrust them to the top of the list. What do we choose to risk? What loss of privacy do we take as given?

And perhaps most importantly: how do we start baking guardrails into our operating systems and platforms? We cannot assume people will configure things correctly, or with a security-first mindset. The modern computing environment must protect us from ourselves. Not a small ask.

Small aside: OpenClaw was originally called Clawdbot, and was effectively a Claude advertisement. Anthropic legal went after them, so they changed the name. Then OpenAI bought them, and won all the reflected glory of one of the most successful open source stories of all time. Talk about missed opportunities.

Reflections On The Mission

My mobile phone is useless for calls. The sheer volume of sales and spam calls means I no longer pick up if I don’t recognise the number. Never mind scam and phishing calls.

I don’t know how my number got into RocketReach, ZoomInfo and the like - but once it did, it ruined my ability to pick up the phone to an unknown number.

But this causes problems. I miss important calls from my bank, and similar institutions trying to get hold of me.

That’s just phone calls. The issue exists with pretty much every interaction with the outside world. Aside from scams and spam, many of our processes rely on barriers to entry to not become unmanageable. Posting a job on LinkedIn already invites hundreds of “Easy Apply” submissions, but if you ask even the simplest question (“Tell me in two paragraphs why you want this job”), 90% don’t respond. With AI, most of them will.

It is becoming impossible to differentiate between something useful, slop and scams. AI removes the friction filter, and amplifies the noise. Something has to give.

I think that trust and reputation systems are going to start being embedded into many of our interactions.

This was done before with email domains - so we just need to do something similar, on a much larger scale. Reputation scores then tagged to individuals - using some kind of ID system like Worldcoin, or country-specific alternatives.

Of course trusting that trust infrastructure becomes its own problem - there have been multiple blockchain-based projects to try and tackle that, such as Affinidi.

Mitchell Hashimoto is one of the world’s most famous open source developers, and he has recently launched vouch - a platform for community trust management. His initial use case was to prevent people submitting useless AI-generated code changes to his projects. Unless someone has vouched for you, you can’t contribute.

Over time, I am sure that this trust infrastructure will extend to agents - both for the agent, and for the functionality and data sources that the agents visit. Trusted agents will be given freer access than those that are unvouched for. Sites that other humans and agents have rated accurate will be given precedence as the agent searches for information.

An exciting future, but I’ll be happy enough if we just fix things well enough that I can start using my phone again.

Interesting Articles

• Something Big Is Happening — matt shumer - this went viral, and while some of it may be a little hyperbolic, the core message is absolutely true: Something Big is Happening.

• From vibe coding to agentic engineering - the author Sau Sheong is CTO of Singapore’s GovTech, and is a highly respected leader in the field. Always worth listening to what he has to say! 

• World Monitor - vibe coded goodness for when you need to monitor the situation.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

88% of companies are using AI.
Only 6% are seeing meaningful impact on EBIT.

That gap isn’t about tools. Or talent. Or data infrastructure. It’s about alignment.

Most organisations treat AI as an efficiency upgrade. Automate a process. Speed up a workflow. Optimise what already exists. The result? Promising pilots that never scale.

Anton Chislov, Fractional CTO at MISSION+, reframes the problem using the McKinsey 7-S model. Strategy, Structure, Systems, Shared Values, Style, Staff, Skills. The top 6% don’t just “do AI.” They reorganise around it.

They delete before they automate.
They redesign before they optimise.

If your pilots are stuck in “almost ready to scale,” this is the diagnostic you need.

Read the full breakdown here and score your organisation across all seven dimensions.

And like that… We’re into February. Luckily, I had some quiet time in January to think about AI-augmented product development, and I would like to share some insights:

Speed Compounds. Clopus 4.5 smashes out great code. But it takes 5 minutes. That used to seem like greased lightning. Now… Come on mate, hurry up! Allegedly there will be a new faster model (Sonnet 5??) released on Tuesday. I can’t even imagine what this looks like in a couple of years.

The Return To Waterfall. Sort of. The premise of Agile assumes that developer time is critical, so it optimises for minimising rework. Agile doesn’t move faster, it tightens feedback loops and avoids futile activities (like much of planning). No longer. Developer time is comically cheap. A rethought ‘sprint’ is 50% ensuring the specification is correct, 30% validating what was built. That’s a mini-waterfall. And that’s fine.

What Was Old Is New. UML, ITSM, TOGAF: strong frameworks that failed in practice because overhead was unbearable (enter Agile). But if AI is creating the artifacts, then formal rigour suddenly beats our arbitrary flailings. These ideas were always solid, we just couldn’t make them work in a realistic scenario. The academics have re-entered the fight.

Mi Parolas Esperanton. If we’re barely reading code anymore, then skill with Claude Code overrides specific languages. I don’t really care if your platform is written in Java or C++, I care more that I know how to get Claude Code to optimise it. This is a wild departure to previous approaches to hiring and training.

Testing, Interrupted. Generated code usually works first time. Unit tests may no longer be the base of the pyramid. Focusing on integration tests, and their associated mocks, makes more sense.

Context Is King. Job number one is getting all of the relevant documentation into context. Onboarding docs? In context. Bugfix FAQ? In context. Project roadmap? You guessed it. Spec Driven Development handles this, but since code is the ultimate documentation, perhaps putting everything into a monorepo and offering it up is best? The consensus is that this approach is correct. I am skeptical; Clopus can go on a side quest and “fix” code completely unrelated to the task at hand (plus search overhead). I think a well-defined mechanism to share API and library function definitions with the agent is more important than the literal code definitions.

Volatility does not equal speed. Agents change a lot of features, fast. Source code volatility becomes difficult, and as orchestrators and architects we need to factor out the hotspots quickly in order for multiple developers and agents to play well together on a shared code base.

Poets of Code, Lament. The quality of code will go down. But as long as it does what the author intends, this will increasingly not be a problem - you’re not writing for human readers any more. Security concerns are more important than ever: vibe then verify.

The Only Way Is Up. Yeah ok some of your code is shitty. With every upgraded model, we can reassess the codebase and we’ll improve it. We’re still so early.

As my boy Scar once said: Be Prepared.

Reflections On The Mission

As a bored young child, I found the section of our family Amstrad computer’s manual on the programming language BASIC. I was hooked.

I had a passion for creating useful products out of my imagination - which continued unabated as I became a teenager, went to University, got a job.

But as one progresses through their career, other things become important. Stakeholder management. Sales. Project tracking. People leadership.

There is nothing stopping you from doing all that stuff and still writing code. But it’s very disruptive to flow, and it takes a while to context switch. See the famous Paul Graham article: Maker's Schedule, Manager's Schedule. 

Let’s call this Time To Flow. How long does it take before one achieves a state of flow?

Without flow, coding is not fun. So it becomes increasingly difficult to have fun coding. Eventually, most give up and resign themselves to becoming some form of manager.  The Time To Flow is too high a price, we can’t carve it out.

This has changed. It is my belief that Claude Code has unlocked a repressed desire in an entire generation of senior technologists.

The unlock is almost instantaneous Time To Flow. With Clopus at my fingertips, it feels like seconds. 5 minutes between meetings? Plenty of time to smash out a feature!

Perhaps a linguistic clue was there all along - Claude Code is great at context management, and we literally call this distraction context switching. By outsourcing context, we can focus on build.

And build we do! The passion is back after all those years.

This is unprecedented, and shifts the success criteria to agency and taste. Perhaps not for every domain - low latency trading systems jump to mind - but for the majority of human endeavour? You bet your ass. Plus those outlier areas have specialists deep in the flow anyway.

How does one build agency and taste? That’s a harder question. In my mind it mostly comes down to Just Fscking Do It. It’s only through trying that we work out what we’re good at, and more importantly what we enjoy.

There are probably parallels for other domains. Do you have a passion, unobtainable due to the Time to Flow? Try Claude Code or Cowork - it’s not just for coding!

And I think over the next few years we’re going to see a bunch of grizzled veterans coming out of retirement, purely for the love of the game…

Interesting Articles

• AddyOsmani.com - 21 Lessons From 14 Years at Google - surprisingly high quality. Mandatory reading for tech workers in any large organization.

• Introducing Cowork - Claude Code level capability for the rest of the company? What could possibly go wrong?! Still, better than installing OpenClaw.

• A Final Message From Scott Adams - the Dilbert creator died, but left a message for us. I don’t agree with everything he believed in, but I think we can all agree that Dilbert provided a brief laugh when we may have needed it most. Fsck I’m getting old.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Happy New Year! May 2026 bring us all everything we deserve 🥳

Let us reflect back over the last year. For builders such as ourselves, we were gifted with a pace of technological change that is probably unmatched in all of history. A year ago, I summarised the momentum going into 2025 as “Google” and “China”. How did I do?

I’m glad to see the Google prediction definitely play out; they are crushing it across the board. The Gemini 3 series show that Google is not going anywhere in the foundational model space, and Nano Banana continues to blow my mind when it comes to ‘understanding’ the images it ingests or produces. The world models produced through Genie 3 are a little ahead of their time, but I suspect 2026 is when this is going to hit the mainstream consciousness.

The China prediction was perhaps a little safer - the buds of DeepSeek and Unitree were already emerging… But I underestimated the widespread astonishment the world had for DeepSeek R1 last January. Nvidia dropped 17% off the back of concerns that more efficient models would change the game - which in my mind was such an obviously incorrect prediction that I hope everyone bought that dip. Since then, we’ve seen Qwen from Alibaba and the Hailuo & Minimax series from MiniMax top benchmarks, amongst other challengers. And that’s not to mention the mindblowing fighting robotic antics from Unitree and Engine.ai.

So how else did 2025 play out? I think one of the bigger surprises for me was the lack of agentic AI adoption on any major level by non “AI native” companies. I was not expecting autonomous agents to have success (due to non-technical reasons), but I thought intelligent workflow would. I think the difficulty has been the “long tail” of capturing context - there’s just too many signals that are based on prior (uncaptured) experience, random side conversations, articles which have been read but not recorded, etc. I’m not sure how we fix that one.

However, the integration of AI into the Software Development Life Cycle (SDLC) has picked up pace - a pace I only see increasing in 2026.

Andre Karpathy really captured the zeitgeist with the term “vibe coding”. Earlier on, this captured all manner of activity - but I now like to distinguish between:

• Vibe prototyping - apps built with Lovable, Replit or Base44 that have no place in production, but are an amazing tool for business users, product owners or designers to visualise their ideas.

• Vibe coding - using AI to augment the delivery of product by (mostly) technical users in a relatively traditional environment.

2025 was just one short year, but we’ve seen two distinct waves. The first came from Cursor and friends: Integrated Development Environments (IDEs) based on the industry standard open source VS Code. By integrating AI, developers became more productive and it seemed this would become the new standard… But it always felt a bit clumsy - I previously described it as the “steering wheel being in the wrong place”.

Enter Claude Code (since copied by Codex, Open Code, Gemini CLI and more). This shift in paradigm moves the developer to a higher abstraction - directing and checking the AI agent in a more straightforward (but paradoxically more powerful) fashion. Personally, I’m hooked with the approach - anyone technical should at least try it.

Looking forward for a 2026 prediction, I fall upon these two insights:

1. The Gap Widens. Particularly when it comes to AI-augmented SDLC productivity, the gap between those taking advantage and those not will become increasingly clear in outcomes. In 2025 we were still figuring things out, so the changing world wasn’t particularly reflected in actual activity. This year it will.

2. Impact from Geopolitics. The world is a complicated place, I won’t comment further on that. But as builders, we do need to think about what this means for us, and possible approaches to things like the “East/West hedge” (having alternative software and infrastructure providers in the unlikely event that traditional supply chains become disrupted).

Enjoy 2026 everyone!

Reflections On The Mission

As we start a new year, my mind turns to Activity vs Outcomes.

Confusing the two is one of the most damaging traps we can fall into. And yet, our very bodies seem wired for it - the dopamine hit of ticking a box has been weaponised into Candy Crush and message notifications.

Why is it so damaging? Firstly, Activity can feel like Progress - but it’s a vanity metric at best. More dangerously, the activity itself becomes addictive, even at the expense of Progress. Lots of small - but ultimately irrelevant - completed tasks ‘feels’ like a win. 

After working in both corporate and startup environments, I feel the startup’s need to distinguish between Activity and Outcomes is what leads to the successful startup being able to create products while the corporate often languishes.

One area where this gets blurry is Operations. The Outcome for Operations is often “don’t fsck it up”. Getting to the end of the day with all breaks resolved, all ledgers reconciled and all widgets accounted for is the Outcome. Reaching this Outcome is often the result of careful, diligent Activity.

This is a good thing, and needs to be recognised as such. Many an Operations employee has struggled with the end of year review: “What did I achieve this year? I didn’t fsck it up!”.

Conversely, this is why many people trying to switch from Operations into e.g. Sales struggle - they get to the end of the day having filled out all their Salesforce forms and forecasts, and take it as a win. It’s not. Selling the widget is the win.

However, in the absence of Outcomes, you better have plenty of Activity! Didn’t hit your sales target this month? OK cool, show me the two million meetings you had. Outcomes over Activity, but Activity over Nothing.

As I’ve become older and more jaded wiser, I have learnt to suppress another Activity vs Outcomes side-effect: the dangerous belief in fairness. “It’s unfair that I’ve been working so hard and didn’t get the big promotion, whilst Bob barely did anything except complete those critical projects. He even took shortcuts for a lot of it”. Effort feels moral.

Yeah mate, but Bob achieved an Outcome. Some of the smartest, most hard-working people I know have struggled to get ahead - whilst the ostensibly lazy, smooth-talking operators cruise forwards. Life isn’t fair that way, nor should it be.

The advances of technology have always helped reduce the need for Activity, and this is only becoming more true with AI and intelligent workflow automation. Focusing on the Outcomes is ever more important.

And so I remind myself to keep this in mind as we go into 2026. What are the Outcomes I really want to achieve? What is the Activity that we can do without, or automate? Where can I prioritise that much better? Wish me luck!

Good luck in 2026, and may we all be the best version of ourselves.

Interesting Articles

• New Ways to Corrupt LLMs - fascinating look at how setting context in a seemingly irrelevant way dramatically affects behaviour. 

• History LLMs - interact with a handful of LLMs that are only trained on data before a given year (e.g. 1913). Can they predict the future based on what they know?

• A Guide to Claude Code 2.0 - quite a technical article, but should be something to learn in here for any Claude Code enthusiast.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Crowdfunding was meant to democratise capital.
Instead, creators pitch in the dark and investors guess their way through campaigns.

The creator economy is racing toward $500B by 2027, yet most creators are still trapped by ad revenue, brand deals, and platforms that own the audience—not the creator. Crowdfunding hasn’t fixed that. It’s static, slow, and built on hype over proof.

The real problem? Crowdfunding platforms don’t measure what actually matters: community trust and engagement. Investors see polished videos, not real traction. Creators ask for belief instead of showing momentum.

In this piece, Arjun, Fractional CTO at MISSION+, breaks down why traditional crowdfunding fails creators—and how Web3 infrastructure quietly rewires the model. Think programmable trust, real ownership, and fans becoming co-owners, not donors.

If you care about the future of the creator economy, this is worth your time.
The shift isn’t speculative. It’s structural.

Read here.

Managing General Agents (MGAs) are reshaping the insurance industry with speed, capital efficiency, and lean teams. Now, AI is helping them move even faster.

From streamlining underwriting to unlocking real-time insights for capital providers, MGAs are proving what’s possible when you combine modern tech with sharp market focus.

In his latest deep dive, Christopher Pile, Managing Partner and CTO at MISSION+, explores:

• What sets MGAs apart from traditional carriers

• How companies like Coalition and Blue Zebra scaled fast with lean ops

• The growing pains MGAs face as they expand

• How AI-powered systems are solving these challenges from the inside out

Read the full article and see how modern MGAs are building the future of insurance.

Everyone wants automation.
Fewer manual steps. Faster workflows. Cleaner operations.

Yet most automation projects stall before they ever reach production.

The problem isn’t the idea.
It’s readiness.

Polished demos make automation look effortless. Click a button, magic happens. But those demos quietly skip the messy reality: access, infrastructure, authentication, APIs, and data flows. Without them, even “simple” automations hit blockers on day one.

This article breaks down what automation readiness actually means — and why it’s the step most teams overlook. From cloud infrastructure and single sign-on to API access and hosting, it explains the invisible foundations that determine whether automation accelerates your business… or slows it down.

If you’re serious about workflow automation delivering ROI — not just demos — this is required reading.

Read the full article to understand what needs to be in place before you automate.

And just like that, we’re in December. Speaking personally, this whole year has gone quickly: whether it was due to having a second child, MISSION+’s expansion, the non-stop assault of new technology, or a mixture of all of these - 2025 was a year with cause to celebrate. As in previous years, I’ll write a year-end review soon.

The Singapore Fintech Festival was as fun as expected - with plenty of opportunities to catch up with the network, plus loads of learning and sharing sessions. I really enjoyed my panel talking about Agentic AI in the commerce and payments space. The collaboration between the big players (VISA, HSBC, Ant Financial & Google Pay were all represented) was further along than I expected. Expect big announcements in 2026.

Reflections On The Mission

“The outcome of any given company is the vector sum of the people within it.” - Elon Musk. For the non-mathematicians, when we add vectors, we add the amplitude of the (in this case) person with the direction that it is pulling. So two equal but opposite vectors have a sum of zero. Two equal but aligned vectors have a sum that is double the original.

This simple observation explains the dysfunction of many organisations - where everyone is pulling against each other, with no clear goal. This is normally unintentional - simply due to poor management. But it is grimly amusing to compare accidental with deliberate dysfunction.

The declassified CIA Simple Sabotage Field Manual from 1944 explains how to sow dissent and kill productivity within an organisation. Turns out that the default state of a company is chaotic, and not that different from deliberate sabotage. Active managerial alignment and weeding out the timewasters is required at every stage.

Let’s take a look at some of the CIA’s sabotage advice.

General Interference

Make long speeches? Refer matters to large committees? Advocate “caution” in the face of action? You don’t need the CIA for that, the natural entropy of organisations seems to pull in this direction. We must consciously fight it.

Managers and Supervisors

Item ‘10’ jumps out at me. “Be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers.” There is nothing more offensive to the human condition than an attack on our sense of fairness and equality.

Employees

“Never pass on your skill and experience to a new or less skillful worker”. We have all seen this play out, where fearful employees hoard knowledge. A sign of a healthy culture is when the sharing of information is commonplace.

When sabotage is laid out so clearly, the opposite constructive approach is equally clear:

• Bias For Action - just do it, get feedback, and iterate.

• Keep committee discussion to a minimum, and focus on small, accountable groups.

• Default to transparency - in the absence of light, darkness prevails. 

• Don’t confuse activity for outcomes - much of this sabotage relies on us monitoring movement, but ignoring if we’re actually hitting goals.

This is The Way.

Interesting Articles

• The Ultimate AI Agents Roadmap for 2025 - a goldmine of resources to get up to speed on agentic AI.

• Star Trek Disco: The Prime Directive is to Dance - this is as good as AI video gets. The future is getting freaky.

• Bullying is Not Innovation - Amazon has asked Perplexity not to use their AI Agents on the site. A sign of things to come, I am sure - the etiquette, guardrails and compliance for agents is super immature.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Browser extensions and productivity plugins promise to make life easier.

But in the rush to automate and accelerate, most teams aren’t addressing the elephant in the room: how much access these tools actually have.

In our latest article, MISSION+ Fractional CTO Daniel Pieper unpacks The Convenience Trap.

From browser extensions quietly reading our data to AI copilots plugged into every inbox and calendar, Daniel explains why the line between “helpful” and “harmful” has never been thinner.

If your teams are experimenting with AI tools to move faster, this is a must-read on how to balance speed, trust, and security.

It’s been a hard month for the hyperscalers. AWS had a massive outage that basically brought down the internet, then Azure managed to follow suit right before a Microsoft earnings report.

I’ve heard a couple of naive souls gloat about these outages… Oh my sweet summer child! We never take pleasure in other company’s infrastructure downtime. Behind all the marketing, the poor bastard trying to get stuff back online is someone just like you or me. He or she is doing their best to get things back up and minimise the impact on those who depend on it.

Worse, you’re tempting the gods. Infrastructure and low level provisioning is hard - we should feel empathy, not amusement, at the woes of others. Instead, we should approach every outage as an opportunity to learn more about distributed systems, where they go wrong, and where it is cost-effective to prevent problems.

After all, there are only two kinds of companies: those who’ve had an outage, and those who will.

MISSION+ Update

The circus is back in town. For those of you in Singapore, the 10th FinTech Festival is just around the corner! Our CTO Ned will be moderating a panel on Agentic Commerce: Solving for Trust, Transparency, and Commercial Models.

After a long day furiously finteching, you’ll need to switch it up - so mosey on down to our evening event:

We look forward to seeing you at both events - it’s going to be a fun week for sure!

Reflections On The Mission

The idea of the “prompt engineer” has never quite sat well with me. It is undoubtedly true that some prompts are better than others, but the concept didn’t quite fit. Not least because AI can be used to “improve” or augment a prompt, and most modern LLMs automatically do that for you anyway.

It all smelt a bit like “Google fu”. In the early 2000s, a person could be “good” at using Google by knowing how to structure a Google query, or through the use of optional operands such as “-” (exclude term), “OR” (search independently for two words), or “daterange” (when the page was indexed). Over time, these became redundant as Google got better at figuring out what you - and specifically you - wanted.

“Context engineering” on the other hand immediately resonates. When reframed in this new terminology, the benefits and pitfalls of how you have structured the context window becomes more obvious.

A model’s context window is made up from the system prompt (the fixed setup provided by the model) and the user prompt. That user prompt is effectively “programming” the model, and guides the response. In a conversation with a model, each message adds to that window - that’s how it knows what has already been said, and retains conversational memory.

Retrieval Augmented Generation (RAG) extends this idea: all we are really doing is allowing the system to try and find additional information to inject into the user prompt - for example the relevant section from your FAQs for a question.

But the context window for each model has a fixed upper size limit; plus the larger it is, the more tokens consumed (and therefore the cost increases). Quality of response also deteriorates as the context window gets filled up - facts and details get lost. If not, we wouldn’t need RAG, we would simply dump every piece of organisational knowledge into context.

Enter the context engineer. Through best practices, tooling and experience, they become experts at populating the context window with sufficient knowledge to drive an optimal balance of output quality vs cost & accuracy.

Areas of context window engineering I see developing include:

• Knowledge management “plugins” for agents, potentially via MCP, for RAG-style context augmentation

• Organisation-wide prompts that set style, guardrails, and shared knowledge, that are added to every query

• Memory - LLMs don’t “learn” over time, but agent learnings could be added to a memory sub-component, which is then dynamically added to the context window (e.g. Mem0 or Letta)

• Personalisation - one’s own preferences could be added to the window. Perhaps we own a “personalisation wallet” that can be accessed by authorised agents?

• Auto-compaction of the context window - there will be redundancy in the content of the window, and the models will get better at compacting that automatically.

• Plus of course the skills and experience of the context engineers themselves

All of this runs much deeper than simply writing better prompts. Over time, our ability to understand, shape and manipulate the context window will improve - just as the window itself gets larger, cheaper and more accurate.

Prompt engineering was a skill. Context engineering is the profession.

P.S. We missed an opportunity to call the context window the attention span. So be it.

Interesting Articles

• Everything Is Becoming a Bank - everything is a bank. Even airplanes.

• Why do AI company logos look like buttholes? - I… I have nothing to add.

• Developer Productivity AI Arena - which AI coding models actually perform the best in real-world scenarios? LET THEM FIGHT.

This Is The Way

Feature A Fractional

We’re On A Mission

Until next month. Together, We Build {+}

Ned & the MISSION+ team

P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to hello@mission.plus!

Cloud platforms play a key role in digital transformation. But when businesses skip the fundamentals, these tools deliver cost without control.

In this article, Thomas Smart, Fractional CTO at MISSION+, breaks down 12 foundational missteps that quietly kill performance and scalability in cloud adoption.

Using the “uncertainty matrix” model, Thomas starts with the known-knowns: the essential tasks every organisation should have locked down but often doesn’t.

From secure landing zones to consistent encryption practices, these steps build the foundation for a cloud strategy that actually scales.

Because when you get the basics right today, you unlock meaningful results tomorrow.

Read Thomas’ full article: Unlocking Real Value from Cloud in 12 Basic Steps

AI chat agents are becoming everyday tools inside companies, but few leaders realise just how exposed these tools leave their business.

From leaked strategy decks to ungoverned employee chats, the risks are meaningful. And without basic safeguards like 2FA, organisations are one hack away from disaster.

In our latest article, Daniel Pieper, FCTO at MISSION+, lays out a clear case for why AI data security must become a boardroom priority. He breaks down the technical and compliance threats, before showing how companies can regain control with the right methods.

If you’re relying on convenience over control, this is your wake-up call.

Read Daniel’s full perspective on why AI needs a healthy dose of caution.