The open standard that lets AI agents actually use your tools and data, in plain English, and what it does not solve.

If you have wired an AI assistant to a single tool, you know the pain: a bespoke connector, hand-built, for that one job. The Model Context Protocol, MCP, is the industry's answer to that. It is the standard way to plug AI models into the tools, data and systems they need, so you build the connection once and reuse it everywhere. Here is what MCP actually is, why it exists, and the honest limits before you let an agent loose on production.

What is MCP?

MCP, the Model Context Protocol, is an open standard, introduced by Anthropic in late 2024, for connecting AI models to external tools and data through one common interface. The usual analogy is a USB-C port for AI: instead of a different cable for every device, one standard connector everything speaks. A model that speaks MCP can read a file, query a database or call an API through the same protocol, rather than a custom integration per tool. In December 2025 Anthropic handed MCP to the Agentic AI Foundation, a fund under the Linux Foundation, so it is now governed in the open rather than by a single vendor.

The pieces that matter

You do not need the whole spec, just three roles. The host is the application the person uses, such as an AI assistant or an IDE. The client lives inside the host and holds one connection. The server is the small adapter that exposes a tool, a data source or an action to any MCP client. Build one MCP server for your ticketing system and every MCP-aware model can use it. That is the shift: connectors become reusable, not rebuilt per model.

Why it matters

• One integration, many models. Because the protocol is standard, you wire a system up once and any MCP-capable model can use it, so you are not rebuilding the same plumbing for each new model.

• It is becoming the default. After launch it was adopted by other major providers, and the move to the Linux Foundation makes it a shared standard, not one company's roadmap.

• It is how agents get real reach. MCP is the mechanism by which an agent moves from talking to acting: reading your systems and taking actions in them.

The honest ledger

• It is a protocol, not a guardrail. MCP standardises the connection; it does not decide what an agent should be allowed to do. Permissions, approval and accountability are still yours to design.

• Security surface grows. Every MCP server is a new door into a system. What it exposes, and who can reach it, is now an operational and security question, not a lab one.

• It is young and moving. The spec is evolving through working groups and proposals, so expect change, and check how mature the servers you rely on actually are.

• Standardising access is not the same as understanding it. You still need to observe what your agents do through these connections, or you have automated actions you cannot see.

So, is MCP for you?

If you are putting AI agents anywhere near real systems, MCP is the plumbing you will end up using, so it is worth understanding now rather than after an incident. The honest question is not whether to adopt it, but how you govern it: which actions you expose through MCP servers, who approves the risky ones, and how you watch what the agents do. Adopt the standard, but decide the guardrails first.

Where are you letting agents act through MCP, and how are you governing it? I would like to hear it, especially the near-misses. Reply or book a slot and tell me what you found.

Related to the byte-sized series

• When The Agent Acts, Who Owns The Decision?

• byte-size: What Is OpenTelemetry?

• byte-size: What Is eBPF?

Sources / further reading

• Anthropic introduction: anthropic.com

• Model Context Protocol docs: modelcontextprotocol.io

• Model Context Protocol overview: Wikipedia

Automating the routine can quietly de-skill your best responders. This is how to keep the edge on purpose.

In this drop

• The point: Automating triage removes the small daily reps that kept your team sharp, so the next novel incident finds them rusty.

• Why it matters: The cost is invisible on your dashboards. It only shows up on the one incident that matters most, weeks later.

• Try this next week: Run one live incident drill the automation cannot help with. A novel fault, no runbook, your best people, cold.

The point

A while back I watched one of the best incident teams I have worked with get quietly worse over about six weeks, and everything we did to them was, on paper, an improvement. We automated triage. The routine incidents got caught and handled, fewer people were woken, the numbers looked wonderful.

Then a genuinely novel fault arrived, the kind that is in no runbook. The team that used to eat those stalled. They reached for the automation, which had never seen it either, and the humans were slow and tentative. Nothing about them had got worse as people. We had taken away their reps.

People in dangerous work drill the basics far more than seems necessary, because the reps buy down the risk on the day it is real. Every routine incident used to be a small rep. We automated the boring reps away, and the edge went with them.

Reality check

What changes everything: the number to watch is not how well you handle the incidents you automated. It is how well you handle the ones you could not.

One proof

Lisanne Bainbridge named this in 1983, in a paper called the Ironies of Automation: the more you automate a process, the more the operator's manual skill decays, so the human is least practised at exactly the moment automation fails and hands the problem back. Field note, from one team I worked with and not an industry benchmark: once we automated the routine triage, the share of incidents the humans actually handled fell by roughly a third within a quarter, and the first genuinely novel fault after that took them noticeably longer than their old form. The people had not changed. Their reps had.

Where this breaks

This breaks if you read it as an argument against automation. It is not. Automation is worth having. The failure is treating it as free and never replacing the reps it absorbs. Keep the automation; add the drills back deliberately.

Try this next week

Schedule one live incident drill, and make it one the automation cannot help with.

Pick a novel fault that is not in the runbook. Get your best responders in a room, real or virtual, and let them work it cold: no script, no automated summary.

Notice how rusty they have got. That is the signal. Then make the drill a habit, because the routine work is no longer sharpening them for you.

Three links I am watching

• Lisanne Bainbridge, 'Ironies of Automation' (Automatica, 1983): the original and still the clearest statement of the skill-decay problem.

• Google SRE, the 'Wheel of Misfortune' disaster role-play: a lightweight way to give a team reps on incidents that have not happened yet.

• Signal Drop 21, 'You're Going To Have To Suffer Today': the companion on rehearsing the bad night before it arrives.

One question for you

When did a novel incident last find your team rusty, and had automation quietly stopped giving them the reps that used to keep them sharp?

Allan

Stop doomscrolling for tech news

TLDR is the free daily email that does the reading for you. Each issue summarizes the most interesting stories in startups, tech, and programming, curated by ex-Google and Anthropic engineers, so you get the signal without the noise.

It's one email instead of 12 open tabs. A 5-minute read with your morning coffee, and you walk in already caught up.

Tech is just the start. We also cover AI, marketing, dev, and more, so you can follow the topics that matter to your work.

Free, daily, and read by 7M+ subscribers. Subscribe and get your mornings back.

Subscribe for Free

For the last couple of years, the only question we really asked about these systems was whether the answer was any good. You typed something in, it came back with text, and you decided what to do with it. The accountability question barely came up, because a human was still the one who acted. The model advised. A person pressed the button, and that person owned what happened next.

That arrangement is quietly ending. The systems are moving from answering questions to taking actions on the business's behalf. The agent does not tell you the order is ready to be placed. It places it. It does not suggest the service might need a restart. It restarts it. The interesting question is no longer how good the answer is. It is the one who owns the action.

I started thinking about this again, watching the agentic-future framing land at Meta's Conversations event, where the pitch was agents that do not just reply to a customer but carry out the transaction for them. The platform numbers in a keynote like that are a marketing slide, not evidence, and consumer messaging is not my field. But the shape underneath it is one I keep running into in operations, and the shape is what matters.

The shift is in the risk, not the convenience

It is easy to read "agents that act" as a convenience story. The work that used to take three clicks now takes none. That framing misses where the change actually lands.

When a system only advises, the risk sits with the human who chooses to act on the advice. The decision, and the ownership of the decision, never leaves the room. When the system acts, the decision leaves the room. Something now happens in the world (an order placed, a refund issued, a production service bounced) without a person in the loop at the moment it happens. The convenience is real. So is the transfer. You have moved the action out of human hands, and unless you were deliberate about it, you have moved the ownership of the outcome to nobody in particular.

That is the part most rollouts skip. We get excited about what the agent can now do, and we forget to say who is responsible when it does the wrong thing at the wrong time.

The question everyone skips

Here is the question. The moment an agent takes an action, someone owns the outcome. Who is it.

Most organisations cannot answer cleanly. They can tell you who built the agent, who pays for it, and who was in the demo. Ask who owns the decision the agent makes at two in the morning, and you get the answer that should worry you most: the team. "The team" owns it. Which is to say no single named person does, because an outcome owned by everyone is owned by no one, and that becomes obvious at exactly the worst time.

This is not a new failure. It is the oldest failure in operations wearing new clothes. We have always had automations that act: the script that scales the cluster, the rule that reroutes traffic, the job that clears the queue. The good ones had an owner, a person who understood what the automation did, who got the call when it misfired, and who could be asked, afterwards, why it did what it did. The bad ones were inherited, undocumented, and owned by whoever happened to be holding the rota when they went wrong. Agents make this question louder because they act across more of the business and with more apparent independence. They do not change the question.

The same question, two very different rooms

Picture two rooms. In one, an agent is booking a customer's order over a messaging app. In the other, an agent is restarting a production service in the middle of a degraded night.

These feel like completely different problems. One is commerce; one is ops. One has a customer on the other end; one has an on-call rota. But the accountability question is word-for-word identical. When the booking is wrong, when the restart takes down the thing it was meant to protect, who owns that outcome? And in both rooms, the failure mode is identical too: if the honest answer is "the team", you have an accountability gap, and the gap does not announce itself until the action has already gone wrong.

The reason this matters is that the commerce version and the ops version are converging. The same pattern (an agent empowered to act on the business's behalf) is arriving in the customer channel and in the control plane at the same time. If you only ever reasoned about it as a customer-experience feature, you will import the same unowned-automation problem straight into production, where the blast radius is your own estate.

Automate the action. Never automate the accountability.

So what does owning it actually look like. The model I trust is approval by blast radius, and it is not complicated.

You sort the actions an agent can take by what happens if they are wrong. Low blast radius (the action is cheap to reverse and contained if it misfires) and the gate can be open: let the agent act, log it, review the pattern later. High blast radius (the action is expensive, customer-facing, or hard to undo) and the gate stays human: the agent prepares the action, a named person approves it, and the act and the approval are both recorded. The dial is not "automated or not". It is "how much can this break, and has someone agreed to own it at that level".

The rule that holds the whole thing together is this. You can automate the action. You must never automate the accountability. Every autonomous action an agent is allowed to take needs a named human owner attached to it before it is switched on. Not a team. A person, who understands what the agent does in their area, who gets the call when it goes wrong, and who can answer for it afterwards. The agent does the work. The named owner keeps the responsibility, because responsibility is the one thing you are not allowed to hand to a process.

This is also what makes the system improvable. When an action has an owner, a bad outcome has a person who notices, investigates, and tightens the gate. When it does not, the same bad outcome just happens again, a little more expensively each time, until it is big enough to become everyone's problem and therefore still no one's.

Buy the agent. First buy the answer.

None of this is an argument against agents that act. The capability is genuine and a lot of it is worth having. Buy the agent if it earns its place.

But buy the other thing first. Before you let a system act on the business's behalf, decide who owns each thing it is allowed to do, and write the name down. The technology question (can it do this) is mostly solved and getting cheaper by the month. The question that decides whether this goes well for you is the one nobody is selling: when the agent is wrong, and at some point it will be, who answers for it. Assign that owner before the agent ever takes its first action, or you will be assigning it mid-incident, which is the most expensive moment to discover you never did.

I spent Thursday at the Emirates Stadium for Dynatrace Innovate London. I went as an independent voice, not a buyer and not a seller, with a bag of books and one question I ask at every event like this: what is your team actually wrestling with right now?

The vendor keynotes were polished, and the platform demos did what platform demos do. And while Dynatrace is definitely leading the pack, that’s not what I want to write about. The part worth your time was the customer stories, so cool, and from the coalface. When peers and practitioners stand up in front of three hundred people and describe what worked, what did not, and what they are still nervous about, you learn more in forty minutes than a year of analyst decks will teach you. Three patterns ran through every one of them.

Pattern one: the foundation came first, always

Not a single customer who reported real gains from AI had started with AI. They started with the boring work. A regulated bank described six months of ingesting logs, wiring up queries and building dashboards before any of the clever automation arrived. A large photo-products group described merging five legacy platforms and roughly 200 microservices, and getting their telemetry in order before they let a model near any of it. Their line was the one I keep repeating to clients: work out what needs to be true for you before AI can take part.

This matters because a broken foundation does not stay neutral when you add AI. It gets amplified. Point a model at noisy, disconnected, half-instrumented telemetry and it will give you confident answers that are wrong. The firms seeing value had earned it by doing the groundwork first. There is no shortcut, and anyone selling you one is selling you a future incident.

Pattern two: the unit of measure moved from health to outcome

The most striking talk of the day came from a national hospitality brand. Their observability leads did not talk about uptime or error rates. They talked about a booking screen that took around 2.7 seconds to load, the work they did to bring it closer to 1.4, and the revenue and customers that the shift was worth to the business. On stage, they put numbers to it. I will not repeat those figures as fact, because a slide at a vendor event is a claim and not an audited result, but the framing is the point: they measured a technical change in customers retained and pounds earned, not milliseconds saved.

That is the shift I have been arguing for in the book and the newsletter. For years, observability answered the question "Is it up?" The teams pulling ahead are answering a different question: "What is it worth?" When you can connect a load-time improvement to conversion, you stop begging for engineering time and start being asked for more of it. The tool matters far less than the decision to make business impact the unit of measure.

Pattern three: the human is coming out of the loop slowly, and on purpose

Every customer was moving toward more automation, and every serious one was doing it with the brakes on. The bank had cut its incident root-cause time dramatically by putting natural language over its query engine, so an ordinary engineer could ask a question instead of waiting a day or two for an expert to write it. The honest detail was the best moment of the session. Their own words, roughly: it is not one hundred percent correct, and that is the point. It gets the team to the right area fast. It is not yet reliable enough to trust blind.

That is exactly the right posture, and it is rarer than it should be. They are drafting fixes automatically and still routing them through a human, in a regulated shop, with guardrails, and only planning to remove that human once confidence and controls justify it. Nobody in the room who runs something that matters was automating the accountability. They were automating the toil and keeping the judgement. If you have read anything I have written on trust-gated operations, you will know why that made me happy.

The line I wrote down

The afternoon had a communication session that had nothing to do with observability and everything to do with why good observability work still fails to land. The speaker's favourite line was this: the winner of the communication race is the person who speaks last. He talked about the curse of knowledge, the trap where the more you understand, the more you assume everyone else does too. He described the job of a technical leader as director of translation, turning MCP, DQL and distributed tracing into something a board can act on.

I thought about every brilliant observability programme I have seen stall, not because the engineering was wrong, but because nobody translated it upward. If you run one of these teams, that is your real second job. You are not only building the platform. You are the chief storyteller for what it makes possible, and if you cannot tell that story to the people who hold the budget, the platform does not get its second year.

What I took away

Innovate London was a good day, and the credit goes to the customers who stood up and were honest, not just triumphant. Strip away the vendor gloss and the message from the floor was steady and unglamorous. Build the foundation before you reach for AI. Measure what the business measures. Automate the work, keep the human on the accountability, and remove that human only when your guardrails have earned it. Then go and learn to explain all of it in plain language, because the best observability in the world is worth nothing if the person paying for it cannot see what it bought them.

None of that is new. It is just easier to believe when three hundred of your peers are nodding along in a football stadium.

Allan Mann is the author of Metrics & Mayhem: A CTO's Guide to Observability That Actually Works and writes the Observability Digest.

We can all recite our resilience numbers. Four nines of uptime. A recovery time objective measured in minutes. A recovery point objective that the business signed off on in a meeting nobody enjoyed. These numbers live on dashboards, in board packs, in the slide that gets dusted off every audit. They are the language we use to say "we are in control".

There is one number we never put on the board. How long would it take to leave the platform that everything else is built on? Not the cost of leaving, although that is bad enough. The time. The elapsed wall-clock months between deciding to go and actually being gone.

I started thinking about this properly after listening to Barry Pilling pull apart the Broadcom, VMware and Tesco licensing dispute on the Tech Leaders Podcast. The legal detail is not my lane, the case is unresolved, and I have no view to offer on who is right. What stayed with me was the shape of the problem underneath it. A customer builds an estate around a platform over many years, the terms of that platform change in a way the customer did not choose, and at that exact moment the most important question in the room is one nobody had measured: how fast can we get out.

The number nobody boards

We are precise about almost everything else. We will argue for an afternoon about whether a service needs three nines or four. We will model failover regions, run game days, and write recovery runbooks for outages that may never happen. All of that is good work, and I am not knocking it.

But ask a leadership team how long it would take to migrate off their core observability platform, or their hypervisor, or their primary cloud, and you get a pause. Then an estimate that is really a hope. Then, if you push, an admission that nobody has actually tried to cost it, because trying to cost it would mean admitting how deep the roots have gone.

Exit time is a resilience number. It belongs on the same board as your RTO and your RPO, because it measures the same thing they do: your exposure when something outside your control goes wrong. The difference is that an outage is an act of weather and a change of terms is an act of will. Someone on the other side of a contract can decide to create your worst day. If you cannot state your exit time, they already know it and you do not.

The day the terms change

Resilience planning has a quiet assumption baked into it. The threat is failure: a region falling over, a disk filling, a dependency timing out. So we design for failure, and we are good at it.

The threat that exit time measures is different. It is not that the platform breaks. It is that the platform works exactly as designed, and the commercial reality around it shifts. An acquisition. A new pricing model. A licensing change that lands the week your renewal does. The platform is still up. Your problem is that you cannot afford to stay and cannot quickly leave.

This is where the embedded customer discovers something uncomfortable. Every integration that made the platform more useful also made it harder to leave. The deeper the value, the longer the exit. And the lever that decides what happens next, the speed at which you could credibly walk, is held by the other party in the negotiation, not by you. You optimised for capability and quietly sold off your optionality to pay for it.

Observability lock-in is the exit time you cannot see

I will bring this home to the discipline I actually work in, because observability is a near-perfect case study in exit time growing while nobody watches.

Think about how a mature observability estate gets built. You start with one vendor's agents because they are easy. Then your dashboards encode a year of hard-won operational knowledge in that vendor's query language. Then your alerting logic, the rules that decide who gets the call at three in the morning, lives in their system and nowhere else. Then your data sits in a proprietary format in their storage, priced by ingest and retention in ways that are hard to predict and harder to escape. None of these decisions was wrong on the day you made it. Each one was the sensible, shippable choice. Together they are a set of roots that take years to grow and, if you ever need to, years to pull up.

That is the part that should worry an operator. Exit time in observability is not a line item you can see. It is the sum of a hundred reasonable integrations, each of which added a little capability and a little lock-in, and you only find out the total on the day you try to leave. By then, it is a discovery, not a decision.

The honest version of this is not "never commit to a vendor". Commitment buys you real things, and a heterogeneous estate held together with string has its own failure modes. The honest version is: know the number. Treat the depth of your commitment as a measured quantity, not a vibe.

Designing for exit

If exit time is a resilience number, then you manage it the way you manage the others. You measure it, you review it, and you do the engineering that keeps it inside a range you can live with. A few things make the difference, and none of them is exotic.

Own your data in an open format. The single biggest driver of exit time is data you cannot take with you in a shape anyone else can read. Open formats and standards exist precisely so that your telemetry is portable by default rather than by heroic project. If your signals are stored in a format only one vendor can read, your exit time is whatever that vendor decides it is.

Own your storage, or at least own the decision about where it lives. The further your data sits from a proprietary, all-in-one bundle, the cheaper and faster it is to point a different tool at it. Separating where the data lives from what reads the data is one of the highest-leverage architectural choices you can make for portability.

Test portability before you need it. Resilience that has never been exercised is a guess. We do not trust a backup we have not restored. We should not trust an exit we have not rehearsed. A small, honest extraction test, can we get a month of one signal type out and into something else, tells you more about your real exit time than any architecture diagram.

Keep a live migration estimate. Not a perfect one. A current, deliberately rough number, owned by someone, reviewed when your estate changes materially, and reported alongside your other resilience figures. The value is not precision. The value is that the number exists at all, and that someone is watching it move.

The point of all this is not paranoia about vendors. It is the same instinct that makes us write a runbook for an outage we hope never comes. We are not predicting the bad day. We are making sure that if it arrives, our options are wider than the other party assumes.

Close

You can probably state your uptime to four nines without checking. You can quote your RTO from memory. Those numbers are real, and they matter.

Now try the other one. If a platform you depend on changed its terms tomorrow, how long would it take you to be gone? If you can answer that with a number you have actually tested, you are in a stronger position than most organisations I have seen. If you cannot, the silence is the answer, and it is not a comfortable one.

Resilience was never only about surviving failure. It is about keeping your choices open when someone else would prefer them closed. Exit time is how you measure that. Put it on the board.

I write about this kind of thing, the numbers we should be tracking and the ones we actually do, every week in the Observability Digest. If the idea of exit time as a resilience number is new to you, the newsletter is where I work these arguments out in the open. If you would rather start with the book, the fourth chapter of Metrics and Mayhem is free.

A single map of the open-source observability stack, and the honest catch on every piece.

The open-source observability world looks crowded until you see the shape of it. Almost everything sorts into four jobs: collect the telemetry, ship it, store it by signal, and look at it. Here is the whole stack in one place, with a link to the plain-English, honest read on each tool.

Every tool is mapped to the signal it owns and how they connect.

The pieces, and the catch on each

• Collect and ship. OpenTelemetry is the vendor-neutral standard that produces the data, though it is a framework, not a backend. Grafana Alloy is a distribution of the Collector. eBPF is the kernel technology behind zero-code collection, and Odigos puts it to work with no code changes.

• Metrics: Prometheus, the default, now OTLP-native. The catch: cardinality and the memory wall.

• Logs: Loki, cheap by design. The catch: weak at open-ended full-text search.

• Traces: Jaeger, the open, standard trace backend, and the concept behind it, distributed tracing. The catch: the storage behind it is the real work.

• See it: Grafana, one pane over all three. The catch: a green dashboard is not a healthy system.

• Go deep: the OpenTelemetry Collector implementation guide for the full how-to.

How it connects

OpenTelemetry is the shared wire format, the language the pieces agreed to speak. A collector like Grafana Alloy gathers everything and routes each signal to its home. Prometheus 3.0 and Jaeger v2 now speak OTLP natively, so the seams keep shrinking. Pick the pieces you need, and hold on to one thing: the tools are the easy part. The honest work is in cardinality, sampling, storage cost, and whether anyone acts on what the dashboard shows.

You signed up for the Observability Digest, and it went quiet for a stretch. It is back now, on a clearer footing.

The Signal Drops you have been getting in between, on the people-and-leadership side of running observability under pressure, are deliberate, and they stay. What was missing was the monthly round-up you actually subscribed to, and a clear promise for it. So here it is: observability you can act on, whether you build it or lead it, plus the few signals worth your time. My read on what actually mattered is the spine, technical where it needs to be; a short list of outside reads is the supporting act. Monthly for now, fortnightly once the rhythm holds.

One ask before you read on. Tell me which cut you want and I will sort the rest:

• Reply TECH for the hands-on, practitioner cut.

• Reply LEADERSHIP for the strategy cut.

• Do nothing to keep the full issue.

One word. Change it whenever.

This month's deep dive

Security just bought observability. A $3.35bn deal closed, two more followed, and the vendors have now decided security and observability are one market. The teams have not: roughly 80% already share the tools, only about 45% agree on how to use them. You can buy the converged platform. You cannot buy the converged team.

🎧 Listen: the podcast  ·  📖 Read the companion piece: on the blog

Analytics on Live Data. No Pipeline. Just Postgres.

Most teams treat analytics as a separate problem. As data grows, they add a warehouse, a pipeline, a sync job. By the time data reaches their dashboard, it's already stale.

TimescaleDB takes a different approach: extend Postgres instead of splitting away from it.

Your transactions and your analytics run on the same database, on live data, with no pipeline in between.

Hypertables partition time-series data automatically as volume grows. Hypercore compression cuts storage by up to 95%. Continuous aggregates pre-compute rollups so dashboards stay fast without re-querying everything.

CERN runs it on Postgres to handle sensor data from the Large Hadron Collider.

No second database. No migration. Same Postgres you already know.

Get $1000 Credit To Start

On the blog this month

I publish these to the site, not your inbox, so here is the month in one place (round up EVERY web-only blog):

• The Regulator Is Not the Brake on AIOps. It Is the Design Spec. The honest state of AIOps in regulated banking: only about 2% of AI in financial services runs fully autonomously, and the gates that earn the rest. Read it.

• SecOps is buying observability; the deep dive above is on the blog for the long read. Read it.

From my feed

A few things I posted this month that landed:

• Most observability spend goes to detection, the 10%. The dashboard shows what you measured, not what matters. The other 90%, coordination and ownership, is where the time actually goes.

• The next tool is not the answer. The arrival fallacy in ops: the thing we chase was never on the other side of the purchase; it was on the other side of the work.

• The loudest person in the incident channel is a signal, not a problem. Anger is usually fear wearing a hi-vis vest, pointing straight at the risk.

I post these as they land. Follow on LinkedIn.

Worth your attention

Outside reads that earned it this month:

• Palo Alto completes its $3.35bn Chronosphere acquisition, the deal that started this conversation. Palo Alto Networks

• Forrester on why this is a dual-motive, AI-driven move, and who gets subordinated. Forrester

• Snowflake buys Observe; Cisco moves for Galileo. The convergence did not stop in 2025. TechCrunch

Worth a listen

Four I actually listened to this month, two technical, two on leadership:

• Charity Majors on observability 1.0 vs 2.0 (podcast interview): why the "three pillars" were a vendor convenience, and what wide events and high cardinality actually change.

• Open Observability Talks (Dotan Horovits): OpenTelemetry's CNCF graduation and where eBPF continuous profiling is heading. Why OTel is now a safe long-term bet to build on.

• Sir Gareth Southgate on the High Performance podcast: leading under relentless scrutiny, and how rehearsing the hard moment turned England's penalty shootouts from a lottery into a practised process.

• No Bullsh*t Leadership (Martin Moore), "12 Hard Leadership Truths": single-point accountability, speed over consensus, and grace under pressure. Hard truths that map onto running an incident.

That is the reset. Monthly, short, judgement first. If a month is light, it stays short. Next month I take the convergence question one layer down: who actually gets the call when the merged platform goes dark.

Allan

📕 The book is out. Metrics & Mayhem: A CTO's Guide to Observability That Actually Works. Kindle, paperback and hardback.

• Get the book on Amazon

• Read a free chapter

• Listen on Spotify and Apple Podcasts

• Follow Allan on LinkedIn

One-line promise: A two-minute read on switching leadership modes under pressure without turning the room into noise.

In this drop

• The point: Your role changes by moment. Sometimes every five minutes.

• Why it matters: Staying in one mode too long turns manageable incidents into chaos.

• Try next week: Ten-second check before any call. Pick the mode. Say it out loud.

The point

In IT Ops, leadership isn't a personality trait. It's a response to the moment.

Some moments need a decision. One owner, one next step, one time check. Other moments require you to step back entirely and let the people closest to the problem breathe. Some need you to coach without stealing the wheel. And some need you to step back and clear blockers while someone else drives.

The mistake most leaders make isn't picking the wrong mode. It's not picking at all. They default to whatever feels comfortable. Usually, the mode that makes them feel useful, not the one the room actually needs.

Under pressure, that gap between what feels right and what is right gets expensive fast. Stakeholders pile in. Updates start looping. People talk over each other. Someone wants a timeline. Someone wants root cause. Someone wants reassurance. Ten voices, no control. And the leader is still in coaching mode when the room needed a decision three minutes ago.

I keep four modes simple on purpose. Direct: we need a decision, now. Shield: the team needs space, you manage the noise. Coach: the team is capable but stuck, ask the right question instead of giving the answer. Delegate: someone else should run this, not because you're weak but because they're closest to the problem.

The power isn't in the modes themselves. It's in choosing deliberately instead of defaulting.

Reality check

If you lead in one mode all the time, you're not leading. You're performing.

One proof

External anchor: Situational leadership is a known pattern for a reason. Hersey and Blanchard formalised it decades ago, and the principle hasn't changed: different people and different situations require different leadership behaviour. What changes in ops is the speed. You might switch modes three times in a single incident call.

Field note: Ten seconds. That's all it takes to pick a mode before you speak. One pause, one deliberate choice, and the next 30 minutes of the call run differently. The room stops guessing. People focus.

Where this breaks

This fails when leaders confuse delegation with disappearing. Stepping back without removing blockers and protecting the team from noise isn't delegation. It's abandonment. Delegate mode only works when you stay close enough to clear the path.

Try this next week

Before your next incident call, leadership update, or tense conversation, do a ten-second check.

Ask: What does this moment need? A decision, space, learning, or ownership?

Pick the mode. Say it out loud at the start of the call: "I'm going to run this in direct mode for ten minutes. One owner, one next step, then we regroup."

Re-check after 15 minutes. If the call is drifting, deliberately switch modes.

Three links I'm watching

1. Hersey and Blanchard's Situational Leadership model. The original framework. Still holds, just faster in ops.

2. Google's incident command system documentation. How structured role-switching works at scale during incidents.

3. Will Larson's writing on engineering management modes. Practical thinking on when to direct, when to coach, and when to get out of the way.

One question for you

Which mode do you default to under pressure, and what does your team pay for it?

Allan

PS: Want the audio version? Listen to the Signal Drop here: [Spotify link]

You can't promise your team a quiet launch. You can give them the bad night in advance. That's what a pre-mortem is.

In this drop

• The point: A pre-mortem isn't pessimism; it's naming the hard moment in daylight so it's recognised, not feared, at 3am.

• Why it matters: Teams that rehearsed the bad moment treat the first wobble as information; teams that assumed calm treat it as catastrophe.

• Try this next week: Run a ten-minute pre-mortem before your next launch: it's 3am and this broke, tell me the story.

The point

A launch I'll never forget, for the wrong reasons. Tested, load-tested, dashboards green. Forty minutes in it wobbled, and the team fell apart. Not because the wobble was huge. Because nobody had told them it was coming, so the first trouble read as 'it's all going wrong' instead of 'here's the hard moment'.

I heard a story this week about a dad and his ten-year-old before a cup final. Instead of 'relax, have fun', he said: you're going to have to suffer today, there'll be a moment you feel you can't win. It came. The boy played through it, because he'd been warned. The other team, winning then losing, fell apart, because nobody had told them.

You cannot promise a quiet launch. What you can do is tell the team where it's going to hurt before it hurts. That's a pre-mortem: it's 3am, two days from now, this has gone wrong, what broke, who's awake, what do they reach for.

Reality check

What changes everything: a team that rehearsed the bad night meets the first wobble with recognition, not panic.

One proof

Gary Klein formalised the pre-mortem in Harvard Business Review in 2007: imagine the project has failed, then work backwards to why. Field note: on one rota, after we started running a ten-minute pre-mortem before significant changes, time-to-rollback-decision on the incidents that followed dropped from roughly twenty-five minutes to under ten across the next quarter. The team wasn't braver. They'd just met the night before.

Where this breaks

This breaks if the pre-mortem becomes theatre, a document nobody reads on the night. The output isn't the doc; it's a team that recognises the failure shape. Keep it to ten minutes and to the people who'll actually be on call.

Try this next week

Before your next launch, get the on-call people together for ten minutes. No longer.

Ask one question and write the answers: it's 3am, this change broke, tell me the story (symptom, dashboard, who gets the call, first action, rollback, who calls it).

Don't aim to predict the exact failure. Aim to make the shape of a bad night familiar.

Three links I'm watching

• Gary Klein, 'Performing a Project Premortem' (HBR, 2007): the original, two pages, still the best version.

• Google SRE Workbook on incident response: the rollback-decision and command structure this habit feeds.

• Signal Drop, 'Progress Isn't Linear': the companion on expecting the rough patch rather than fearing it.

One question for you

When did a launch last go sideways on you, and would a ten-minute pre-mortem have changed how the night felt?

Allan

📕 The book is out. Metrics & Mayhem: A CTO's Guide to Observability That Actually Works. Kindle is live now; paperback and hardback launched on 1 June.

Analytics on Live Data Without Leaving Postgres

When analytics on Postgres slows down, most teams add a second database. TimescaleDB by Tiger Data takes a different approach: extend Postgres with columnar storage and time-series primitives to run analytics on live data, no split architecture, no pipeline lag, no new query language to learn. Start building for free. No credit card required.

Start building for free

The kernel technology behind zero-code observability, in plain English, and where it stops short.

If you have read anything about modern observability lately, you have run into the same four letters over and over: eBPF. It is the engine under a wave of zero-code tools, including Odigos, that promise traces and metrics with no SDK and no redeploy. It is genuinely clever, and it is not magic. Here is what eBPF actually is, in plain English, and the honest limits before you lean a whole strategy on it.

What is eBPF?

eBPF stands for extended Berkeley Packet Filter, though the name now undersells it. It is a feature of the Linux kernel, the layer every application runs on top of, that lets small, sandboxed programs run deep inside the kernel with no change to the kernel's source code, no module to load, and no reboot. A built-in verifier checks every program before it runs and rejects anything that could crash or hang the system, so the power comes with guardrails. In plain terms, eBPF lets a tool watch what your software and your network are really doing, from the outside, with very little overhead.

A thirty-second history

The original BPF arrived in 1992 as a way to filter network packets for tools like tcpdump. The extended version landed in the Linux kernel in 2014 and turned that narrow trick into a general-purpose way to observe and shape almost anything the kernel touches: system calls, network traffic, function entry and exit. It is now stewarded by the eBPF Foundation under the Linux Foundation, formed in 2021, whose members include Meta, Google, Microsoft, Netflix and Isovalent. That breadth matters: eBPF is becoming a cross-industry standard, and it is even spreading beyond Linux through the eBPF for Windows project.

What it does well

For observability, three things make eBPF compelling:

• No code changes. Because it hooks kernel events rather than your application, you get traces, metrics and profiles without importing an SDK or redeploying. That is what zero-code instrumentation actually means.

• Low overhead, broad reach. Programs are compiled and run inside the kernel, so they capture system-wide signals, every process on the node, network flows and system calls, at a cost most workloads will not feel.

• One mechanism, many jobs. The same technology powers networking, continuous profiling, security monitoring and tracing. Learn it once and it pays back across the stack.

The honest ledger

eBPF is powerful, not free. The gaps are real.

• It needs a modern Linux kernel. Most useful features want kernel 4.x or newer, and the richest capabilities, like BTF and CO-RE that let one binary run across kernel versions, want 5.8 or newer. Older estates such as RHEL or CentOS 7 are simply not supported. The legacy systems that hold the actual money are often the ones eBPF cannot reach.

• It is privileged by nature. eBPF programs run in the kernel and need elevated capabilities. That is a security conversation, not a tick box, and some managed Kubernetes platforms restrict the node-level access these agents require.

• It shows the plumbing, not the meaning. eBPF captures generic runtime and protocol telemetry brilliantly. It does not know your customer journey or your business logic. You still have to define your SLOs and add instrumentation for the spans that matter to your domain.

• It is not trivial to build with. Writing and debugging eBPF is kernel-level work, and when something fails to load the feedback can be thin. Most teams consume eBPF through a tool rather than writing it themselves, which is fine, as long as you know that is the trade.

So, is eBPF for you?

If you run modern, Kubernetes-native Linux workloads, eBPF is one of the best things to happen to observability in years, and you are almost certainly already benefiting from it through the tools you use. If your weight sits in older infrastructure or locked-down managed platforms, treat it as one valuable layer rather than the whole answer, and check kernel versions and node access before you commit. Either way, hold on to the last point: eBPF gets you the data faster, it does not decide what the data means. That part is still your job.

Where have you seen eBPF earn its place, or fall short? I would like to hear it, especially from anyone running it in anger. Reply, or book a slot and tell me what you found.

Related from the byte-size series

• byte-size: What Is Odigos?

• byte-size: What Is Grafana Alloy

• OpenTelemetry Collector Implementation Guide

Sources / further reading

• What is eBPF (project explainer): ebpf.io

• eBPF Foundation (Linux Foundation): ebpf.foundation

• eBPF overview: en.wikipedia.org/wiki/eBPF

• eBPF for Windows: github.com/microsoft/ebpf-for-windows

The vendor-neutral standard for telemetry, in plain English, and what it does not do for you.

If eBPF is the engine under a lot of modern observability, OpenTelemetry is the language everyone agreed to speak. It is now almost everywhere, and in May 2026 it became a CNCF graduated project, the formal seal on what was already the de facto standard. Here is what OpenTelemetry actually is, why it matters, and the honest limits before you rip out what you have.

What is OpenTelemetry?

OpenTelemetry, usually shortened to OTel, is an open-source, vendor-neutral framework for collecting telemetry: the traces, metrics and logs, and now profiles, that your systems produce. Instead of every vendor shipping its own agent and format, OTel gives you one set of APIs, SDKs and a collector that instrument your applications once and send the data anywhere you choose. It is a Cloud Native Computing Foundation project, second only to Kubernetes in activity, with more than 12,000 contributors from over 2,800 companies, and it reached the CNCF's top maturity tier in May 2026.

The pieces that matter

You do not need the whole glossary, just four parts: the instrumentation, automatic or manual, that produces the data; the OTLP protocol that carries it; the Collector that receives, processes and exports it; and the semantic conventions that keep names consistent, so an HTTP request means the same thing everywhere. Tools like Grafana Alloy are distributions of that Collector, and tools like Odigos produce OTel data with no code changes.

Why it matters

• Instrument once, send anywhere. Because the data is standard, you point it at whatever backend you like and switch later without re-instrumenting. That is the end of agent lock-in.

• It is the safe long-term bet. With graduation and adoption at this scale, building on OTel is building on the industry default, not a single vendor's roadmap.

• It unifies the signals. Traces, metrics and logs in one framework, correlated, rather than three disconnected tools.

The honest ledger

• It is a framework, not a backend. OTel collects and ships your data. It does not store, query or visualise it. You still need somewhere for the data to land, whether that is Prometheus, Grafana or a commercial platform.

• Maturity varies. Traces and metrics are stable, logs are maturing, and profiles are still early. Some language SDKs are further ahead than others, so check yours.

• It adds operational surface. The Collector and its pipelines are powerful, and that power has a cost: more to run, and real discipline needed on data volume and cardinality before the bill surprises you.

• Migration is real work. Moving from proprietary agents to OTel pays off, but it is a project, not a switch you flip.

So, is OpenTelemetry for you?

For almost anyone building or running modern systems, yes, and increasingly it is not really a choice: it is the standard your tools already speak. The honest question is not whether to adopt OTel, but how fast, and how much of the pipeline you run yourself versus buy. If you want vendor neutrality and a future-proof foundation, start now, on your most important services. If you need turnkey today, a managed OTel-based offering gets you there without running the plumbing yourself.

Where has OpenTelemetry paid off for you, or tripped you up? I would like to hear it, especially the migration stories. Reply, or book a slot and tell me what you found.

Related from the byte-size series

• OpenTelemetry Collector Implementation Guide

• byte-size: What Is Grafana Alloy

• byte-size: What Is eBPF?

• byte-size: What Is Odigos?

Sources / further reading

• OpenTelemetry project: opentelemetry.io

• OpenTelemetry graduates (CNCF announcement): cncf.io

• OpenTelemetry is a CNCF graduated project: opentelemetry.io/blog

How you follow one request across many services, in plain English, and where it falls short.

In a monolith, when something is slow you read one log. In microservices, a single click can touch a dozen services, and the question "where did the time go?" gets genuinely hard. Distributed tracing is how you answer it. Here is what it is, in plain English, and the honest limits.

What is distributed tracing?

Distributed tracing follows a single request as it travels through all the services that handle it, and stitches the whole journey into one picture called a trace. A trace is made of spans, and each span is one unit of work: an API call, a database query, a function. Every span records when it started, how long it took, and some context, and they nest, so you can see that a slow checkout spent most of its time waiting on one database call three services deep. It is one of the three pillars of observability, alongside metrics and logs.

How it actually works

The real trick is context propagation. When a request enters your system it is given a trace identifier, and every service passes that identifier along as it calls the next one, usually in an HTTP header that follows the W3C Trace Context standard. Each service adds its own spans to the same trace. Break that chain, with a service that does not forward the header, and the trace fragments. This is why a shared standard like OpenTelemetry matters: it makes propagation work across services written by different teams in different languages.

Why it matters

• It shows the path, not just the symptom. Instead of "the app is slow", you see exactly which hop is slow, and by how much.

• It survives complexity. The more services you have, the more you need it. Tracing is what keeps a microservices estate debuggable.

• It turns finger-pointing into evidence. The trace shows which service owns the delay, so the conversation is about the data, not whose fault it is.

The honest ledger

• It is only as good as your instrumentation. Miss a service, or break context propagation, and you get a partial trace that can mislead more than it helps.

• Sampling is a trade-off. Recording every request is expensive, so most teams sample. Sample too hard and you miss the rare failure you most wanted to see.

• It shows where, not always why. A slow span points at the location. You still often need the logs and metrics around it to find the root cause.

• It has a cost. High-volume tracing adds overhead and data, and rich span attributes multiply cardinality, which is where bills grow.

So, is distributed tracing for you?

If you run microservices, serverless, or any request that crosses more than one service, distributed tracing is close to essential, and the modern way to get it is OpenTelemetry, often with no code changes through eBPF-based tools. If you run a single, simple application it matters less, though it still helps. Either way, start with your most important user journeys rather than trying to trace everything at once.

Where has tracing saved you, or let you down? I would like to hear it, especially the sampling war stories. Reply, or book a slot and tell me what you found.

Related from the byte-size series

• byte-size: What Is OpenTelemetry?

• OpenTelemetry Collector Implementation Guide

• byte-size: What Is eBPF?

• byte-size: What Is Odigos?

Sources / further reading

• OpenTelemetry observability primer (traces): opentelemetry.io

• W3C Trace Context standard: w3.org/TR/trace-context

Zero-code observability with eBPF, and the one question to ask before you bet your estate on it.

Every so often a demo actually stops me. Odigos did. I sat down with their team on 7 June 2026, and I will be honest up front: I was impressed. That is exactly why I went and did the homework afterwards, because the tools that impress you in a demo are the ones you most need to pressure-test. So I asked them the questions a careful buyer asks, then checked their answers against the wider world. Here is the balanced read, the good and the awkward, so you can decide for yourself.

What is Odigos?

Odigos is an open-source observability control plane that auto-instruments your applications using eBPF and OpenTelemetry, with no code changes, no SDK to import, and no redeploy. You point it at your Kubernetes workloads and it starts producing distributed traces from running services. It is a Y Combinator company (W23), the open-source project has well over 3,000 GitHub stars, and it was built by people who maintain OpenTelemetry itself. That last part matters more than the star count.

First, what is eBPF?

The whole approach rests on eBPF, so it is worth thirty seconds. eBPF is a feature built into the Linux operating system that lets small, safe programs run deep inside the kernel, the layer every application sits on top of. In plain terms, it lets a tool watch what your software is actually doing from the outside, without you changing a line of code and without meaningfully slowing anything down. It began life in networking and security, and observability tools worked out they could use the same trick to capture traces and metrics almost for free. That is the engine under Odigos.

What it does well

The pitch is simple enough to explain to someone who has never written a line of code. Pick your namespaces, and it instruments them on the fly. In their demo I watched a slow checkout get traced to a database lock wait, and a stalled AI call traced to a token limit, with nobody touching the application code.

Three things stand out once you look past the polish:

• It cracks the hard languages. Compiled languages like Go have always been painful to instrument without code changes. Odigos uses eBPF and the official OpenTelemetry Go instrumentation to get traces out of them anyway.

• It is vendor-neutral by design. Because it emits OpenTelemetry and runs inside your own cluster, you point the data at whatever backend you like and switch later without re-instrumenting. Instrument once, route anywhere. Nothing has to leave your environment, which makes the security conversation shorter.

• It is helping write the standard, not just sell against it. Odigos is a founding contributor to the OpenTelemetry eBPF Instrumentation (OBI) project, alongside Grafana Labs, Splunk and Coralogix. A vendor shaping the open standard is a different proposition from one fencing you in.

The honest ledger

No tool is a free lunch, and the gaps here are real.

• It is Kubernetes and Linux native. eBPF lives in the node kernel and needs a reasonably modern one. When I pushed them on older estates, they were refreshingly straight about it: you need a Linux kernel of 4.18 or newer and Kubernetes 1.21 or newer, and while bare metal is supported, they told me it was not yet running in production at a customer. The shiny cluster is the easy part. The legacy back end nobody can safely re-instrument, the VMs and the older systems that hold the actual money, are where the hard questions live. Coverage beyond Kubernetes is the question, not the headline.

• Depth has limits today. Independent testers have found database calls surfacing as generic operations rather than full statements, and the richest Go auto-instrumentation reported as part of the paid tier rather than the free one. Worth confirming against your own workloads.

• The space is consolidating fast. With Beyla folded into OBI and several vendors converging on one standard, some capabilities are still maturing and the competitive map is moving under everyone's feet.

• Speed is not the same as meaning. eBPF shows you the plumbing in minutes. It does not tell you whether the customer journey is actually working. You still have to define your SLOs and your business logic. That work does not disappear, it just starts sooner.

Is Odigos the right tool for you?

If you run a modern, Kubernetes-native estate and you are tired of waiting on an engineering backlog to get distributed tracing, Odigos is genuinely worth a serious look, and the vendor-neutral, in-cluster design makes it an easy one to trial. If your weight sits in legacy infrastructure, treat it as one piece of the picture and ask hard questions about coverage and data depth before you bet the estate on it.

That is the question I would want answered before I put my name next to anything. Not because the demo was weak. Because it was strong, and strong demos are exactly when you should ask.

Do you have an Odigos story, good or bad? I would like to hear it, especially from anyone running it past a proof of concept. Reply, or book a slot and tell me what you found.

Disclosure: I have spoken with the Odigos team and may collaborate with them on future content. The opinion here is my own and stays honest, including the parts they would rather I left out.

Related from the byte-size series

• byte-size: What Is eBPF?

• byte-size: What Is Grafana Alloy

• OpenTelemetry Collector Implementation Guide

Sources / further reading

• Odigos open-source project and docs: github.com/odigos-io/odigos

• Odigos on Y Combinator (W23): ycombinator.com

• OpenTelemetry eBPF Instrumentation (OBI), first release: opentelemetry.io

• OTel Go auto-instrumentation (eBPF): github.com/odigos-io

• Grafana Beyla / OBI background: grafana.com

This one was recorded after a 3am incident call, close to twenty-four hours awake, with no energy left for pretending.

The burnout worth watching is not the dramatic kind. It is the quiet one. It shows up when your work and your life drift out of alignment and you are too busy to admit it. Pressure on its own does not break people. Misalignment does, slowly, until a night like that forces the clarity you have been avoiding.

Notice one place this week where the drift is showing, and say it out loud to someone you trust. Naming it is how it stops being invisible, and how you start to close the gap.

Listen: the Signal Drop, about 5 minutes

A lot of what passes for leadership is performance. The update that exists to look busy. The ceremony that moves nothing.

The real work is quieter: hygiene, ownership, honest signals. Here is the test I use. If a thing does not improve clarity, stability, or reliability, it is probably theatre. Cut it, and let the team shine instead of watching you perform.

Find one recurring ritual this week that fails that test. Drop it, and see if anyone misses it.

Listen: the Signal Drop, about 5 minutes

Most outages I have ever seen were not surprises. They were someone skipping a simple check because they were chasing something shiny.

The basics are boring on purpose. Patience, consistency, the same checks done the same way. Reliability is not built in the heroic moment. It is built in the dull one, when you are tired, bored, annoyed, and ready to throw the laptop into the sea, and you do the check anyway.

Pick the one basic your team keeps deferring until things calm down. Do it this week, while things are not calm. That is the whole point.

Listen: the Signal Drop, about 5 minutes