DEV Community: Seenivasa Ramadurai

Activation Functions, Explained With a Drone Show

Seenivasa Ramadurai — Thu, 09 Jul 2026 21:16:54 +0000

I was watching a drone light show over a city skyline last week, a thousand drones forming shapes against the night sky, and it struck me that this is one of the cleanest ways to explain what an activation function actually does inside a neural network. No math notation required to get the intuition. Just drones, brightness, and a rule.

Here is the analogy, the actual definition behind it, and where this concept sits inside a real deep learning pipeline.

What Is an Activation Function?

An activation function is a mathematical rule applied to the output of a neuron after it computes a weighted sum of its inputs. It decides whether that neuron fires, how strongly it fires, and what shape the signal takes before it gets passed to the next layer.

Formally, a single neuron computes z = (w1*x1 + w2*x2 + ... + wn*xn) + b, a linear combination of inputs, weights, and a bias term. The activation function is the step applied right after: a = f(z). That f is the activation function, and the choice of f determines the behavior of the entire network.

The core reason it exists: non linearity. Without an activation function, or with a purely linear one, stacking any number of layers collapses mathematically into a single linear transformation. A hundred layer network with no activation function is functionally identical to one layer. You cannot model curves, boundaries, or complex patterns with that. Activation functions are what let a network bend, separate, and represent non linear relationships in data.

Where It's Used in Deep Learning

Activation functions show up at two distinct points in almost every deep learning architecture:

Hidden layers: every neuron in every hidden layer of a CNN, RNN, transformer, or plain feedforward network applies an activation function to its weighted sum before passing output forward. This is where ReLU and its variants dominate today.

Output layers: the final layer's activation function is chosen based on the task. Sigmoid for binary classification, softmax for multi class classification, and often no activation, or a linear one, for regression tasks like price prediction.

This is not an optional add-on. Every trained deep network you have used, image classifiers, language models, recommendation systems, has an activation function baked into every single neuron. It is one of the most fundamental architectural choices in the entire design, right alongside layer depth and width.

The Setup for the Analogy

Picture 1,000 drones in the sky. Each drone is a neuron. A control signal tells each drone how bright to shine. That signal is the weighted sum described above, and on its own it carries no shape, no decision, no meaning yet.

What Happens Without an Activation Function

If every drone just displays its raw signal value directly, you get a mess. Negative brightness values do not make physical sense, so you would need to clip or scale them arbitrarily, and even then there is no rule enforcing which drones should stand out and which should stay quiet. The result is a formless blob of light. No shape, no picture, no decision boundary.

This is the exact real world consequence of skipping the activation function: linear layers stacked without non linearity learn nothing more than a straight line through your data, regardless of depth.

ReLU: The Decisive Drone

ReLU, short for Rectified Linear Unit, follows a blunt rule:

If the incoming signal is negative, the drone turns off completely. No light.
If the signal is positive, the drone shines at exactly that brightness.

Mathematically, f(x) = max(0, x). A signal of -5 means the drone goes dark. A signal of 8 means the drone shines at brightness 8.

The effect at the network level is sharp, clean shapes. Only the neurons that are confident, meaning they received a positive signal, contribute anything. Everyone else stays silent. That is exactly why ReLU became the default activation function for hidden layers across most modern deep learning architectures: it produces sparse, decisive activations, it is cheap to compute since it is just a threshold check, and it largely avoids the gradient problems that plagued earlier activation functions.

The tradeoff worth knowing: if a neuron's signal stays negative across every input it ever sees, it goes permanently dark and stops learning entirely. This is called the dead ReLU problem, and it is why variants like Leaky ReLU and GELU exist, giving negative signals a small nonzero slope instead of a hard zero.

Sigmoid: The Gradient Drone

Sigmoid takes a completely different approach. Instead of an on/off switch, every signal gets smoothly converted into a brightness somewhere between 0% and 100%.

A very negative signal fades toward 0%, but never fully reaches zero.
A very positive signal climbs toward 100%, but never fully reaches max.

The formula is f(x) = 1 / (1 + e^-x). Every drone always emits some light, even if barely visible. The result across the network is soft, glowing gradients instead of hard shapes, which is why sigmoid is still the standard choice for output layers doing binary classification, where you want a smooth probability between 0 and 1 rather than a hard cutoff.

The tradeoff: at the extremes, the curve flattens out almost completely. A signal of -10 and a signal of -20 produce nearly identical output. That flat region means the gradient shrinks toward zero during back-propagation, which is the vanishing gradient problem. Stack enough sigmoid layers and the earliest layers in the network barely learn anything at all. That limitation is a big part of why ReLU displaced sigmoid as the default for hidden layers once networks started getting deep.

Other Activation Functions Worth Knowing

Tanh: similar shape to sigmoid but outputs between -1 and 1 instead of 0 and 1. Centered at zero, which helps gradients flow slightly better than sigmoid, though it still suffers from the same vanishing gradient issue at the extremes.

Softmax: used almost exclusively in the output layer for multi-class classification. Converts a vector of raw scores into a probability distribution that sums to 1 across all classes.

GELU: a smoother variant of ReLU used in most modern transformer architectures, including the ones behind large language models. It weights inputs by their magnitude rather than applying a hard cutoff at zero.

Mapping the Analogy Back to the Architecture

The One Line Takeaway

An activation function is the rule each neuron follows to decide how strongly to fire. Without that rule, you get a formless blob of numbers instead of a network capable of recognizing a pattern. With the right rule, sharp decisive shapes with ReLU, smooth probabilistic gradients with sigmoid, or the smoother curves of GELU inside a transformer, you get a network that can actually learn something.

Next time someone asks why activation functions matter, skip the equations first. Start with the drones.

Thanks
Sreeni Ramadorai

The Architecture of Time

Seenivasa Ramadurai — Wed, 08 Jul 2026 21:56:28 +0000

What AI Taught Me About Living in the Present

Every AI model I build depends entirely on the past. Every mindfulness teacher I've listened to tells me to let the past go. At first those felt like contradictions, one treating history as everything, the other treating it as something to release. The longer I spent building AI systems, the more I understood they weren't opposing ideas at all. They were describing two different kinds of intelligence, and somewhere between them I found something worth writing down.

The Rearview Mirror of the Machine

One of the biggest misconceptions about AI is that it looks into the future. It doesn't. Every prediction a machine makes is built entirely from yesterday, whether it's forecasting demand, recommending your next movie, catching fraud before it happens, or generating the next word in a sentence. There is exactly one source of knowledge behind all of it historical data.

Take that history away and the model doesn't grow cautious. It grows incapable. No patterns, no inference, no prediction, just silence. Machines don't see the future. They learn the past well enough to respond to a moment they've never seen before, and that isn't a limitation we're still engineering our way out of. That's the entire mechanism.

The more I sat with that, the more I suspected we aren't so different. Our experiences are our training data. Every success teaches us something, every mistake leaves a pattern behind, every failure quietly updates our model of the world. The past isn't baggage. It's data.

The Human Edge

This is where we stop resembling the machine. A model cannot choose to ignore its training. We can. Spend too long living in yesterday and memory starts masquerading as identity. Old disappointments harden into expectations, past failures get filed as permanent truths, and yesterday's fear starts making today's decisions without asking permission. We call it experience. Sometimes it's just unprocessed history, still running the meeting.

The present hands us something no machine has ever touched choice. You can interrupt a habit halfway through the reflex. You can forgive someone after years of meaning not to. You can change your mind for no reason except that you've changed, and become someone slightly different between one breath and the next. That capacity isn't a gap in human intelligence. It's the whole point of it. Our history shapes us, but it was never supposed to finish the sentence for us.

The Real Algorithm

So who's right, the engineer who trusts the data or the teacher who says to release it? Both, describing the same truth from opposite ends. Ignore the past completely and nothing accumulates, you just repeat what you haven't yet learned from. Live entirely inside it and you calcify, the human version of an overfit model, tuned to perfection for a world that has already moved on without you. Wisdom sits in the narrow space between those two failures. Not the absence of history. Not its rule. Its use.

Building Your Own Architecture

Next time an old mistake finds its way back into your thoughts, resist calling it a verdict. Call it what it is training data. Take the lesson, and leave the weight where it fell. Your history can brief the decision, but it doesn't get to make it. That belongs to whoever you are in this exact moment, choosing.

Maybe that's the only architecture worth building, one where history informs the moment without ever being allowed to replace it. The future was never something we predict from a distance.

It's something assembled, one present moment at a time, by someone who remembered enough to know better and stayed awake enough to choose anyway.

Thanks
Sreeni Ramadorai

The Architecture of Becoming: Why Your Life is a Transformer Network

Seenivasa Ramadurai — Thu, 02 Jul 2026 03:46:57 +0000

Introduction

For most of my life, I thought my journey followed a predictable, linear script Go to school. Get a degree. Get a job. Gain experience. Get promoted. That was the whole story or so I believed.

Then I spent a few years designing Generative AI systems for a living, and that neat little script stopped making sense.

Most of my days are spent building on top of Large Language Models (LLM) navigating Transformer architectures, RAG pipelines, multi agent workflows, MCP servers, and the guardrail harnesses required to keep the whole thing from going off the rails. One evening, while working through the architecture for an Agentic AI solution to solve a complex enterprise use case, something stopped me.

It wasn't just a system diagram anymore. It looked like a map of my own life. Not in a poetic, greeting card way but in a literal, structural way. The stages matched up almost embarrassingly well.

Here is what I saw, phase by phase.

1. The Vector Space of Childhood

Metaphor: Embeddings

Before an LLM can process a single sentence, it has to turn words into embeddings. Raw text means nothing to a model; it’s just empty symbols. An embedding model places those symbols into a high dimensional vector space where distance and direction carry meaning. Words end up near each other because they share context. Nothing useful happens downstream until this space exists.

The Life Parallel: This is the hidden work of childhood. I wasn’t merely collecting facts; I was building the high dimensional coordinate system those facts would later live in.

My early teachers weren't just handing me information they were shaping my cognitive geometry. A lesson would place a new idea near something I already half understood. A correction would nudge two concepts a little further apart. None of it meant anything in isolation. Looking back, they weren't filling a blank disk; they were establishing the baseline vectors I would use to make sense of the entire universe.

2. The Layers of Understanding

Metaphor: The Encoder Stack

Once you have embeddings, the encoder takes over. An encoder doesn’t generate new text; its sole purpose is to build a deeper, more abstract representation of the input. Each layer takes the output of the previous layer and distills it further.

Formal education did exactly this to me:

Elementary School: Decoded raw symbols on a page.
Middle School: Learned to reason with core concepts.
High School: Introduced systemic abstraction.
University: Grounded those abstractions into engineering.
Graduate Work: Shifted the focus entirely to systems thinking.

Each stage wasn't just a new textbook it was a new layer stacked on top of the last. The outside world hadn't changed at all. What changed was the depth of the representation I could build. When I solve a complex problem today, it’s not because the problem got easier. It’s because I have more layers processing the input.

3. The Reality Check

Metaphor: Validation Sets & Loss Signals

Every model eventually has to leave the clean, synthetic world of the training loop. For me, that happened on day one of my first real job. School had been a highly curated training set labeled, clean, and forgiving. The workplace was noisy, unlabeled, and entirely unimpressed by my resume.

My first internship was a brutal validation set. Reality doesn't grade on a curve; it checks your output against hard constraints.

Every bug I shipped was a loss signal.
Every rough code review was a weight adjustment.
Every design that collapsed in production closed the gap between what I thought would work and what actually did.

I used to think failure meant the learning process had stalled. Eventually, I understood that failure was the mechanism. It wasn't an error in the system; it was the gradient descent optimization of my career.

4. The Act of Generation

Metaphor: Auto Regressive Decoders

At some point, the balance flipped. I transitioned from absorbing context to producing it.

This is the part of a Transformer that gets less attention than it deserves the decoder cannot see what is coming next. It only knows what it has already produced, and every new token depends entirely on the sequence that came before it.

That is exactly what a career feels like after a decade.

The architectural decision I made last year still shapes what I can build today.
The professional reputation I built five years ago quietly decides which opportunities are visible to me now.

I don't get to go back and retroactively edit the tokens I’ve already put out into the world. I can only take the sequence as given and generate the next token as intelligently as possible.

5. The Shift to External Context

Metaphor: Retrieval Augmented Generation (RAG)

There is a persistent myth that being an expert means having all the answers memorized. Modern AI abandoned that ideology a long time ago. A model that only knows what is baked into its static weights is severely limited. Real production systems reach outside themselves triggering a RAG lookup against a technical document or querying a database.

The moment I stopped trying to hold everything in my head and started building better external retrieval systems, my engineering velocity exploded. The strongest leads I know aren't the ones with the most trivia crammed into short-term memory. They are the ones with the most efficient retrieval instincts they know exactly which document, API, or expert to query at the exact moment they hit a constraint.

6. Protocols of Connection

Metaphor: Model Context Protocol (MCP)

As enterprise AI matured, engineers ran into a scaling wall you can't hardcode a model to every single custom tool it might need. It doesn't scale. Tools like MCP (Model Context Protocol) solve this by creating an open, standard interface so models can safely read data and touch tools without tight coupling.

I hit that exact same scaling wall when my career grew past what I could personally manage. I couldn’t sit in every meeting or audit every codebase.

Documentation became my API. Writing clear wikis, run books, and design docs allowed other teams to query my context without needing to interrupt my runtime. I stopped equating value with personal execution and started thinking of myself as an interface that others could cleanly build upon.

7. Dynamic Adaptability

Metaphor: Agent Skills & Lightweight Adapters

A production agent doesn't retrain its entire multi billion parameter foundation model just to learn how to use a new piece of software. Instead, we register Agent Skills scoped, modular capabilities loaded dynamically at the application layer when the environment calls for them, leaving the underlying foundational weights completely untouched.

This is exactly how acquiring a new skill works. Learning Kubernetes didn't rewrite how I think about distributed systems; it just loaded a new "skill" on top of the engineering fundamentals I already possessed. New tech stacks don't erase your foundational experience they are just specialized functional blocks loaded into your prompt context when a specific task demands them.

8. The Enterprise Hivemind

Metaphor: Multi-Agent Workflows & A2A Communication

Nothing serious runs on a single, isolated model anymore. Robust architectures rely on A2A (Agent-to-Agent) communication within multi agent workflows. An engineering agent writes code, a security agent audits it, a compliance agent checks it against regulations, and a financial agent estimates the API cost. None of these agents can see inside each other’s prompt history. They don't need to. They talk asynchronously, exchanging structured messages back and forth. Yet, through this protocol, the hivemind converges on a coherent solution.

That is the exact definition of a cross functional corporate team. Every alignment meeting, sprint handoff, and architecture review is an exercise in A2A communication an exchange of structured text payloads between humans who cannot see each other's internal reasoning. We were running multi agent workflows long before we wrote code for them.

9. The Governance Layer

Metaphor: Guardrails & Evals

If you build production AI systems long enough, you learn a humbling lesson: the most capable model is often the most dangerous one if left unguided. Without evaluators, systemic guardrails, and a strict system prompt, a brilliant model will eventually drift into confident, destructive nonsense. Raw compute requires a harness to be useful.

The Life Parallel: This is what character actually is.

Intelligence tells you what you can do; character determines what you should do. Discipline, integrity, and humility are not products of raw cognitive horsepower. They are the governance layer built around your mind. Over a long enough time horizon, the strength of your guardrails matters infinitely more than the speed of your processing core.

10. The Anchor of the Past

Metaphor: Causal Self Attention

There is a common assumption that education is a phase that ends when work begins a clean line between learning and doing. The architecture of a Transformer proves otherwise.

Most modern models don’t have a separate, isolated encoder pass. Every single token is generated via causal self-attention, looking back across the entire historical sequence generated so far. Nothing gets thrown away once it is in the context window. A token generated at step 5 still directly alters the probability distribution of step 50,000.

That is how my past actually functions.

An architectural decision I make today is still weighted by a principle an old mentor shared twenty years ago.
A leadership choice I make this morning carries the heavy context of my worst early management failures.

The past isn't a dusty archive I occasionally visit; it lives inside my active context window, one attention pass away at all times.

The Break in the Metaphor: Continuous Optimization

Here is where the comparison fundamentally breaks, and it’s the most beautiful part of the realization.

Production machine learning models eventually freeze their weights. The training loop closes, the checkpoint ships, and from that second onward, the model runs static inference. It cannot learn from the user interactions it handles today unless an engineering team aggregates the logs and kicks off an expensive retraining run later.

Humans don't have that limitation.

There is no boundary between our "training phase" and our "production phase." Every hard conversation, every failed launch, and every sudden market shift changes our internal weights in real time while we are actively doing the job. We don't wait for a maintenance window to optimize. We evolve mid flight.

There is no final deployment checkpoint for a person. There is only the next token you choose to generate, and the system you build while generating it.

Thanks
Sreeni Ramadorai

Stop Chasing Smarter Models. Start Engineering Better Context.

Seenivasa Ramadurai — Sun, 21 Jun 2026 04:37:35 +0000

Introduction

We spend our entire lives chasing happiness in the next job, the next city, the next relationship only to realize somewhere along the way that happiness was never out there. It was a state of mind. Something you cultivate from within, not something you find.

Enterprise AI is making the exact same mistake.

Every week, teams pour budget into the next frontier model bigger parameters, wider context windows, stronger benchmarks convinced that intelligence is the thing they're missing. But the agents still hallucinate. The pipelines still break. The outputs still disappoint.

Because the problem was never the model.

Just like happiness, the answer isn't out there in a smarter LLM. It's in the environment you build around the model you already have. It's in the quality of the context the data it receives, the memory it carries, the instructions it operates on.

That is Context Engineering. And it's the discipline most teams are ignoring while they wait for the next model release to save them.

You can hand a genius a disorganized pile of corrupted documents, conflicting instructions, and broken APIs and they will still fail. Conversely, hand an average worker a clean playbook, sharp guardrails, and exactly the data they need and they will execute flawlessly every single time.

That single observation should reshape how every enterprise AI team allocates its engineering budget.

The Illusion of the "Smart" Agent

Most enterprise teams treat LLMs like databases stuffed with world knowledge. They are not. An LLM is a reasoning engine. It doesn't retrieve answers it reasons toward them. The quality of that reasoning is almost entirely determined by the quality of what you put in front of it.

When an agent fails in production, the gut reaction is to upgrade to a larger, more expensive model. But when you actually dig into the execution logs, the root cause is rarely a lack of raw intelligence. It is almost always a data failure:

The system fetched the wrong vector chunk.
The API schema passed to the agent was ambiguous or incomplete.
The conversation history was an unpruned wall of noise.

None of those failures get fixed by a bigger model. They get fixed by better context.

A well optimized, smaller model operating on clean, deterministic context will consistently outperform a massive frontier model reasoning in the dark. I have watched this play out on real enterprise workloads. The model upgrade didn't help. The context pipeline redesign did.

The Token Economy Problem

Chasing raw model intelligence isn't just an engineering trap it's an economic liability.

In enterprise AI, every token is a financial transaction. When you dump unrefined, unstructured data into a massive context window and rely on the model's "intelligence" to sort through the noise, you are paying a premium for a problem that should have been solved upstream. Runtime costs spike. Latency climbs. And the outputs are still inconsistent because the ambiguity was never resolved it was just delegated to the model.

This is lazy architecture. It feels like a shortcut, but it compounds into a long-term cost problem.

The alternative is Context Engineering: building deterministic pipelines that deliver exactly the right information, in the right structure, at the right moment. When you do this well, you stop needing frontier-scale models for routine tasks. You route cheaper, faster, specialized agents to handle the work — and you reserve the heavier models for the exceptions that actually need them.

Context Engineering in Practice

Context Engineering is not a single technique. It is a discipline that spans three layers.

1. Retrieval Quality — Moving Beyond Simple Vector Search

Traditional RAG systems retrieve based on semantic similarity. That works for surface level lookups, but enterprise data is relational. A customer record connects to contracts, which connect to support history, which connect to renewal status. GraphRAG architectures capture those relationships explicitly so the agent receives not just a matching chunk, but the business context that surrounds it.

Simple vector distance gets you close. Knowledge graphs get you accurate.

2. Dynamic Context Pruning — Protecting the Token Budget

Not everything in your context window deserves to be there. Long conversation histories, redundant tool outputs, and boilerplate instructions accumulate fast. Dynamic pruning is the practice of continuously evaluating what stays, what gets compressed, and what gets dropped — ensuring the agent only operates on high-signal data.

Every token you cut from noise is a token you can spend on signal.

3. State and Memory Management — Teaching Agents What to Remember

An agent with poor memory management treats every turn like it's the first. It re-fetches data it already has, loses track of prior decisions, and fails to carry forward the context that matters. Proper short-term and long-term memory architecture ensures agents accumulate useful state across a workflow and discard the rest.

Where Raw Intelligence Still Matters

This is not an argument for dumb models. Intelligence and context are not competitors they are complements.

Context does the heavy lifting for the predictable 80%. It ensures the agent knows where it is, what it has to work with, and what it's supposed to do. For that 80%, a well contextualized smaller model is not just good enough it's better, faster, cheaper, and more consistent.

But the other 20% the undocumented API errors, the unexpected user edge cases, the multi-step recoveries that is where raw reasoning earns its place. You still need intelligence for exception handling. The difference is that you should be deploying it surgically, not as a substitute for good architecture.

Think of model intelligence as the safety net, not the foundation. It catches what falls through. Context engineering is the foundation.

The Shift That Matters

The teams building production grade AI systems in 2025 are not the ones waiting for the next model release. They are the ones mastering the scaffolding that surrounds the model the Agent Harness the context pipelines, the memory layers, the routing logic, the governance controls.

The competitive advantage in enterprise AI is not access to a bigger model. Everyone has access to the same frontier models. The advantage is in how well you engineer the environment those models operate in.

Stop waiting for a smarter brain. Start building a better world for the brain you already have.

Thanks
Sreeni Ramadorai

Most Enterprise AI Agents Fail in Production for the Same Reason And It's Not the Model

Seenivasa Ramadurai — Fri, 19 Jun 2026 01:49:33 +0000

Because intelligence alone is never enough.

There's a question I keep hearing from enterprise teams who are just starting to productionize AI agents:

"We've got great prompts. The model performs well in testing. Why does it still fail in production?"

The reason is almost always the same they built the intelligence. They didn't build the system around it.

That's it. That's the whole failure pattern. The model is fine. The engineering discipline surrounding it wasn't applied.

Here's the analogy I use to explain the difference.

An AI Agent Is a Self-Driving Car

Not metaphorically. Structurally.

Both operate in dynamic, unpredictable environments. Both make real time decisions with incomplete information. Both can fail not because they're dumb, but because the environment surprises them in ways nobody anticipated. And in both cases, the intelligence of the system (the model, the sensors, the neural net) is only one layer of what makes it trustworthy.

When you break it down, three distinct engineering disciplines make a self-driving car work. The same three disciplines make an AI agent work.

Layer 1: Prompt Engineering = Destination and Driving Instructions

Before you put a self driving car on the road, you configure it:

Where are we going?
Which route is preferred?
What's the speed limit?
Are there constraints? (No highways. No toll roads. Arrive by 3 PM.)

The car doesn't invent the mission. You give it one precisely, explicitly, in a format it can act on.

Prompt Engineering does exactly the same thing for an AI agent. It defines:

The goal and scope of the task
The rules and constraints it must follow
The persona and tone it should operate with
The guardrails that bound its behavior
The expected format and outcome of its output

Without clear prompts, the agent does what a car does without a destination it moves, but not toward anything useful. It might wander into edge cases, confabulate, or execute the wrong task with full confidence.

Real example: An Ecommerce support agent told only to "help customers" will happily process a refund, cancel an active shipment, and escalate to a manager all for the same complaint because nobody told it which action to take first, or when escalation is appropriate. The model is working fine. The briefing failed.

Prompt Engineering is the briefing. It's not optional, and it's not a one-time job. As your tasks evolve, so should the prompts.

Layer 2: Context Engineering = Situational Awareness

A self-driving car with perfect instructions will still crash if it can't see what's around it.

That's why autonomous vehicles carry:

GPS and real-time maps
Lidar and radar sensors
Camera feeds processing the road ahead
Weather and road condition data
Traffic pattern feeds
Pedestrian detection systems

All of this is context live, environmental, dynamic information that allows the vehicle to make intelligent decisions in the moment, not just based on pre-loaded instructions.

An AI agent has the same problem. The base LLM is trained on historical data. It doesn't know about your enterprise data, your customer's current account status, the document that was updated yesterday, or the conversation that happened last week.

Real example: A banking support agent is asked "what's the status of my loan application?" The model knows everything about loans in general. It knows nothing about this customer's application filed three days ago. Without retrieval RAG pulling the customer's record in real time the agent either hallucinates a status or says it doesn't have access. Both outcomes destroy trust. The model is fine. The context layer wasn't built.

Context Engineering fills that gap. It's how you inject:

RAG and GraphRAG — retrieval of relevant documents and structured knowledge
Memory systems — both short-term (within session) and long-term (across sessions)
MCP Servers — access to external tools, APIs, and services
Enterprise knowledge bases — internal policies, product documentation, historical data
User history and preferences — the personalization layer
Real-time data feeds — current state of the world the agent is operating in

Context is not a prompt engineering problem. It's an infrastructure problem. Getting the right information to the agent at the right moment, in the right format, with the right freshness that's an entirely different discipline with its own architecture, its own tooling, and its own failure modes.

A well prompted agent with poor context is like a skilled driver in a blindfolded car. The instructions are clear. The execution is impossible.

Layer 3: Harness Engineering = Safety, Recovery, and Accountability

Here's where most teams underinvest.

Even the most advanced autonomous vehicle isn't deployed without a full safety stack.

Collision detection and emergency braking
Lane departure warnings
Route recalculation when roads are blocked
Telemetry for monitoring vehicle state
Black-box logging for post-incident investigation
Human override capability
Regulatory compliance systems
Redundant sensor fusion

This is the harness — the layer that doesn't make the car smarter, but makes it safer. It's the layer that catches failures before they become disasters, and that proves what happened when they do.

Agent Harness Engineering is the same idea applied to AI systems

State Management — knowing where the agent is in a multi-step workflow
Checkpointing — saving progress so failures don't require starting over
Human-in-the-Loop (HITL) — escalation paths when confidence is low or stakes are high
Observability — traces, logs, and dashboards that show you what the agent did and why
Guardrails and Content Controls — preventing harmful or out-of-scope outputs
Tool Access Control — scoping what the agent can call and with what permissions
Evaluation Pipelines — continuous testing against ground truth to catch regression
Recovery Logic — graceful degradation when tools fail or context is unavailable
Security and Governance — audit trails, access controls, compliance hooks

Real example: An HR onboarding agent is mid-workflow — it has created a user account, sent a welcome email, and is about to provision software licenses when the identity service times out. Without checkpointing, the entire workflow restarts from scratch: duplicate account, duplicate email, confused new hire. Without observability, the engineering team doesn't even know it happened until someone complains. The model executed perfectly. The harness wasn't there to catch the infrastructure failure.

The harness doesn't change what the agent can do. It changes what the agent will do under pressure which is when it matters most.

Why Failures Still Happen Even When You've Done Everything Right

Here's the truth every production AI team eventually confronts.

Even with all three layers in place solid prompts, rich context, a well engineered harness your agent will still make mistakes. Not occasionally. Regularly enough that you need a plan for it.

This is not a model quality problem. It is a fundamental property of the environment these systems operate in.

Both autonomous vehicles and AI agents face the same four realities:

Dynamic environments — the world changes faster than any training set or prompt update cycle can track
Incomplete information — no matter how good your retrieval is, the context is always partial
Unseen edge cases — production traffic will surface combinations that no benchmark, red team, or test suite anticipated
Cascading conditions — two situations your agent handles perfectly in isolation can combine into something it has never encountered

No amount of engineering eliminates these realities. What engineering does is change how you respond to them.

You can have:

Clear, tested prompts
Rich, well-curated context
A well-designed harness with observability and recovery

And the agent will still make mistakes. The difference is whether those mistakes are visible, recoverable, and traceable — or silent, destructive, and impossible to debug.

The goal is never zero failures. The goal is:

Detect failures earlier. Recover faster. Prove what happened. Continuously improve.

That's what the harness is for. That's what observability is for. That's what HITL is for.

If someone asks you to explain all three disciplines in a single breath

Prompt Engineering tells the agent where to go. Context Engineering helps it understand where it is. Harness Engineering helps it arrive safely, recover when things go wrong, and prove what happened along the way.

What This Means for Enterprise AI Teams

Most teams are over invested in Layer 1 and under invested in Layers 2 and 3.

Prompt Engineering gets the most attention because it's visible, iterable, and produces immediate results. It's also the layer that impresses in demos. Context Engineering is harder because it requires data infrastructure, retrieval pipelines, and integration work. Harness Engineering is hardest because it requires thinking about failure modes before they happen.

But here's the practical reality: in production, the agents that stay in production are the ones with solid harnesses. Not the ones with the most creative prompts.

The teams that deploy reliably aren't just asking "did the agent get the right answer?" They're asking "when it gets the wrong answer, how fast do we know? How do we recover? What's the audit trail? Who can intervene?"

That's the shift from building demos to building systems.

Final Thought

The autonomous vehicle analogy works because it shifts the conversation from capability to reliability. Nobody debates whether self-driving cars are technically impressive. The debate is always about whether they're trustworthy enough to operate at scale without human supervision.

That's exactly where enterprise AI is right now.

The LLMs are impressive. The question is whether the systems around them are engineering grade.

Prompt, Context, and Harness Engineering are how you close that gap.

Thanks
Sreeni Ramadorai

SAGA Made Microservices Reliable. Agent Harness Makes AI Agents Reliable.

Seenivasa Ramadurai — Sun, 14 Jun 2026 05:31:13 +0000

The distributed systems world solved long-running transactions with SAGA. The agentic AI world has a harder version of the same problem. Here's how Agent Harness answers it.

Introduction

I've been deep in agentic AI architecture for a while now & building Digital Workers, designing multi-agent systems, working through the messy production realities of agents that call tools, consult knowledge bases, and loop back on themselves when they're uncertain. And one question keeps coming up when I talk to engineers who come from a microservices background: "Can't we just use SAGA for this?"

It's a fair question. SAGA is one of the more elegant patterns in distributed systems. And on the surface, agentic workflows look similar enough that the analogy is tempting. Both involve coordinating multi-step processes. Both need state management and failure recovery. Both have to deal with partial completions.

But the moment you dig into the details, you realize why SAGA alone isn't enough and why Agent Harness exists.

What SAGA Was Built to Solve

If you've spent time in microservices land, you've lived this problem. Service A completes, Service B completes, Service C fails and now you have a half-committed distributed transaction with no clean rollback and no database level guarantee to save you.

The SAGA pattern was invented for exactly this. The break long-running transactions into a sequence of local steps, and for every step that can succeed, write a compensating action in advance so that if something downstream fails, you can undo the damage cleanly.

It works beautifully because microservices operate in a deterministic world. Every service has a known API contract. Every response has a typed schema. Every failure is a status code or a typed exception. Every retry is predictable. The failure modes are knowable at design time, so you can write compensation logic at design time.

AI agents don't live in that world.

The Problem Is Probabilistic, Not Deterministic

Here's what fundamentally changes when you move from microservices to agentic AI systems, your "services" are now LLM calls, tool invocations, knowledge retrievals, external APIs or MCP Server tool calls **, and **increasingly human approvals. None of these behave like a well defined REST endpoint with a contract you can write compensation logic against.

An LLM call can return an answer that passes every syntax check but is semantically wrong confidently, fluently, plausibly wrong. A tool call might succeed at the HTTP layer but return data that sends the agent down an entirely incorrect reasoning path. A multi-step task might "complete" having taken three hallucinated intermediate steps before landing somewhere that superficially looks like the goal.

And here's the part that should give you pause: a SAGA coordinator would mark all of that as success. No exceptions. No compensation triggered. Workflow complete.

Retrying won't fix it. Compensation logic won't fix it. You need something architecturally different: an Agent Harness.

What SAGA and Agent Harness Actually Share

Before getting into where they diverge, it's worth being honest about the parallel because it isn't just a clever analogy. It's structurally real.

Both patterns exist to solve the same core problem: coordinating multi-step processes where individual steps can fail, state needs to be preserved across the lifecycle, and the overall system needs to recover gracefully when things go sideways.

The SAGA Coordinator manages: state tracking, retries, compensation actions, failure recovery, workflow sequencing, and distributed reliability. The Agent Harness manages all of those same things just mapped to a completely different execution model.

[The architecture maps cleanly. The implementation is night and day.]

What Agent Harness Does That SAGA Cannot

SAGA assumes your workflow steps are atomic and deterministic. Agent Harness has to deal with steps that are neither. That's why it needs an entire category of capabilities that have no real SAGA equivalent:

Memory (Short & Long Term): An agent working a multi-turn task needs to remember what it decided three steps ago, what the user said at the start, and what it already tried that didn't work. That's not transaction state. That's episodic memory and working context interleaved in a way that needs to survive tool calls, retries, and mid-task handoffs.

Reflection & Critique: Before committing to an action or an answer, a well designed harness routes the agent's proposed output through a self critique step. Did the answer actually address the stated goal? Does it contradict something established earlier in the session? Does it fall outside the policy boundaries? SAGA never needs to ask its services whether they feel confident about their output. Agent Harness does.

Guardrails & Policies: In production especially in regulated industries you don't want an agent calling a sensitive external API, accessing PII, or making a consequential decision without policy enforcement at the harness level. This isn't exception handling after the fact. It's proactive constraint evaluation before execution. I've seen this matter enormously in healthcare projects where the consequences of an unguarded tool call are real.

Human-in-the-Loop: SAGA runs unattended by design. Agent Harness needs to know when to stop and ask a human and that decision happens at the semantic level, not the infrastructure level. "I'm not certain this is what the user intended" is a fundamentally different pause condition than "the API returned a 503."

Evaluation & Validation: Did the agent's output actually achieve the goal? Not "did the tool call succeed" did we actually do what we set out to do? This requires goal level evaluation, not just a success/failure bit. It's one of the harder things to operationalize in practice, but skipping it is how you ship agents that complete tasks without accomplishing goals.

Cost & Token Monitoring: LLM calls have variable cost depending on context length, model tier, and how deep the reasoning goes. An agent running a complex multi-step task can burn through budget in ways that are invisible until you get the bill. A production Agent Harness needs token spend guardrails the way a microservices platform needs circuit breakers on latency.

Durable Execution via Checkpointing: If an agent task runs for 40 minutes and the process crashes at minute 39, checkpointing lets you resume from the last stable state rather than starting over. Philosophically similar to SAGA's compensating transactions but the implementation means serializing agent state, tool call history, memory contents, and intermediate reasoning. Substantially more complex, and substantially more necessary for long horizon tasks.

The Concrete Scenario That Makes This Real

Let me give you a specific example, because abstract architecture arguments only go so far.

Imagine an agent tasked with: "Research our top three competitors' pricing pages and prepare a comparison summary for the sales team."

A SAGA style system would model this as: call tool to fetch Page A → call tool to fetch Page B → call tool to fetch Page C → call tool to generate summary → done. If any fetch fails, compensate. If all fetches succeed, the workflow completes.

But here's what can actually happen: Page B returns a cached version from 2 months ago. The agent doesn't know that it just sees valid HTML. It processes the outdated pricing as current. The summary it generates is factually wrong in a way that could embarrass your sales team.

Every step "succeeded." The SAGA coordinator marks it complete. No compensation triggered. And your sales team walks into a meeting with incorrect competitive data.

Agent Harness addresses this at multiple layers. Reflection catches that the retrieved content has anomalous date markers. Evaluation validates whether the output meets the quality criteria defined for the task. Guardrails can flag when retrieved content falls below a freshness threshold. Human-in-the-loop escalation routes the uncertainty to a person rather than silently proceeding.

That's the gap. And it's not a small one.

The Key Difference, Plainly Said

SAGA manages deterministic workflows. Agent Harness manages probabilistic workflows.

In SAGA, failure modes are knowable at design time. You write compensation logic once and trust it to cover the cases. In an Agent Harness, failure can mean: the tool returned a valid response that the agent misread. Or the agent completed every step correctly but arrived at a goal that doesn't satisfy what the user actually wanted. Or the agent is in a soft reasoning loop, re-checking the same condition because it's genuinely uncertain and nobody told it when to escalate.

Handling that requires reflection, self critique, goal validation, and graceful human escalation none of which exist in the SAGA vocabulary, because SAGA was never designed for an execution unit that reasons about the world.

What This Means If You're Building Today

If you're designing an agentic system and you're thinking purely in SAGA terms, you're probably building something that's reliable at the infrastructure layer but brittle at the reasoning layer. Your agents will retry correctly. They'll compensate correctly. But they'll also confidently produce wrong answers, hallucinate tool results, and mark tasks complete that aren't — and your coordinator will have no way to know the difference.

Agent Harness is the layer that closes that gap. It's not a replacement for orchestration. It sits above orchestration and asks: did we actually do the right thing, in the right way, within the right constraints, with the appropriate level of human oversight?

The engineers who built SAGA were solving a genuinely hard distributed systems problem. The people building Agent Harness today are solving a harder version of it because the failure modes are less visible, the state is messier, and "success" is much harder to define when your execution unit is a language model reasoning about an open-ended goal.

But the spirit is exactly the same: build systems that fail gracefully, recover intelligently, and complete what they started.

SAGA made microservices reliable. Agent Harness is what makes AI agents reliable.

One Question Worth Sitting With

Of all the Agent Harness components, I've found that Reflection & Critique and Human-in-the-Loop are the two that teams most consistently underinvest in usually because they're harder to wire up than checkpointing or token monitoring, and the cost of skipping them isn't visible until something goes wrong in production.

Which component do you find hardest to implement in practice and how are you handling it? I'm genuinely curious what patterns the community is landing on. Drop it in the comments.

Thanks
Sreeni Ramadorai

AI Agents Are the New Microservices & A2A Is Their HTTP(s)

Seenivasa Ramadurai — Fri, 29 May 2026 23:14:43 +0000

Introduction

As enterprises race to deploy generative AI Apps/Agents, the hardest question isn't "which foundation model do we use?." it's "how do they safely talk to each other?"

If you spent the 2010s building distributed systems, the architectural blueprints emerging for enterprise AI will feel strangely familiar. Bounded contexts, service registries, async message queues, and distributed tracing are all back. The vocabulary is almost identical except our "services" now reason in natural language, call tools, and produce probabilistic, context-aware outputs instead of deterministic ones.

The Agent-to-Agent (A2A) Protocol is the open-standard transport and interface layer that makes this architectural analogy concrete. And ,the protocol now has support from more than 150 organizations including Salesforce, Microsoft, SAP, Workday, PayPal, and LangChain.

Just as HTTP/REST became the lingua franca of Microservice communication, A2A (now hosted under the Linux Foundation) standardizes how autonomous agents discover capabilities, delegate tasks, and maintain security boundaries.

Defining the Ecosystem: A2A vs. MCP

To design an enterprise multi agent mesh, you must first separate agent orchestration from tool execution. A common architectural anti pattern is trying to force a single protocol to handle both.

Model Context Protocol (MCP): This handles the Agent-to-Tool layer. It standardizes how a single agent securely reads from local databases, hooks into enterprise storage, or accesses development environments.

Agent-to-Agent Protocol (A2A): This handles the Agent-to-Agent layer. It standardizes how separate, sovereign intelligent systems communicate with each other in their natural, semantic modalities (negotiating tasks, passing conversational state, or handing off workflows) across frameworks and lines of business.

The key distinction: MCP connects agents to tools (vertical integration). A2A connects agents to each other (horizontal integration). They are explicitly designed to be complementary, not competitive. Together, they form the two-layer interoperability stack for modern multi-agent systems.

Under the Hood: How A2A Actually Works

Before diving into communication styles, it helps to understand the technical foundation A2A is built on because it is deliberately not reinventing the wheel.

A2A leverages well established web technologies.

HTTP/HTTPS — primary transport layer (production deployments require HTTPS with modern TLS)
JSON-RPC 2.0 — structured data exchange format for all requests and responses
Server-Sent Events (SSE) — real-time, one-way streaming of updates from agent to client

Every A2A agent publishes a small JSON document called an Agent Card, typically served at /.well-known/agent.json. This file lists the agent's identity, skills, endpoint URL, and authentication requirements — enabling zero-configuration discovery between agents without any proprietary registry or coordination layer.

Security is baked in from the start. A2A incorporates enterprise-grade authentication and authorization mechanisms aligned with OpenAPI security schemes, including support for OAuth 2.0 and API keys passed via HTTP headers.

The Four A2A Communication Styles

The A2A standard defines clear execution modes that mirror the structural communication patterns distributed systems engineers have relied on for decades.

1. Synchronous (Blocking)

One agent sends a task and blocks its execution context until the responding agent returns a final artifact.

Microservices Analogy: A standard REST call (GET /resource).

AI Use Case: Fast, critical path dependency queries like an Orchestrator agent requesting a real time risk compliance score before formatting a customer response.

2. Asynchronous (Non-Blocking)

One agent dispatches a task object and immediately returns to other processing. The remote agent queues the work and processes it in the background.

Microservices Analogy: Message queues or event streams (Kafka, RabbitMQ).

AI Use Case: Long-running cognitive tasks such as a Legal Agent reading a 400-page corporate acquisition contract or a Data Agent running complex batch classification.

3. Streaming

Continuous data tokens or partial states flow dynamically between agents in real time, rather than waiting for a single completed payload.

Microservices Analogy: gRPC streaming or Server-Sent Events (SSE).

AI Use Case: Real-time speech transcription agents feeding an analysis agent, or interactive multi-agent chat interfaces where UX requires instant token delivery.

4. Push Notifications (Event-Driven)

An agent registers a web callback or subscription, receiving a proactive alert only when a specific upstream event or state change occurs. When significant task state changes happen such as completed, failed, or input-required the server sends an asynchronous HTTP POST notification to the client's provided web hook. This requires the server to declare push notification capability in its Agent Card.

Microservices Analogy: Web hooks or an Event Bus.

AI Use Case: Event-driven governance like an automated Compliance Agent waking up to audit a transaction only when an Account Agent drafts a contract exceeding $1M.

Key Architectural Insight: A mature multi-agent enterprise system never forces a single interaction pattern. It builds a mesh that combines all four, leveraging an internal API gateway plane to manage traffic, route tasks, and handle fallback strategies.

The Critical Shift: From Deterministic to Semantic Interfaces

In traditional microservices, the API contract is strictly deterministic: Send these exact bytes, receive those exact bytes.

In a multi-agent network, the interface is semantic: Send this intent, receive a reasoned response.

Instead of maintaining brittle endpoints for every hyper-specific query variation, an agent uses its Agent Card to advertise its overall "Skills" and expected structural input/output schemas. A Finance agent capable of calculating remaining Q3 headcount budgets does not require a new API endpoint deployment when business users slightly pivot the nuance of the request; it interprets the intent via the A2A task lifecycle.

The "beating heart" of this lifecycle is the task's input-required state, which allows agents to pause execution mid-task and request further information from clients or other agents something traditional REST APIs were simply never designed to do. This makes agent conversations stateful and adaptive in a way that static Microservice contracts are not.

Conclusion

The parallels between the microservices revolution of the 2010s and today's multi-agent AI ecosystem are not just cosmetic. The same hard-won lessons around service discovery, security boundaries, async communication, and composable architecture are being relearned and encoded into open standards like A2A and MCP.

A2A is an open standard that enables AI agents to discover, communicate, and transact with each other across different frameworks, vendors, and platforms. MCP handles how each of those agents connects to its tools. Together they give architects a principled, two-layer model for building AI systems that are modular, interoperable, and production-ready.

The momentum behind A2A growing from 50 launch partners to 150+ organizations in under a year underscores something simple fragmentation in AI agent ecosystems is a problem the industry is collectively choosing to solve. For engineers building in this space today, the question is no longer whether these protocols matter. It's whether your architecture is ready for the systems around you that already use them.

Thanks
Sreeni Ramadorai

The Agent Harness Taught Me Why I Used to Fail

Seenivasa Ramadurai — Thu, 28 May 2026 21:08:18 +0000

On building AI agents and accidentally understanding yourself

Introduction

We tend to believe that intelligence is the ultimate differentiator that if we think clearly enough, know enough, and work hard enough, success follows. It's a comforting idea. It's also incomplete.

I didn't fully understand that until I started building AI agents.

Specifically, it hit me while designing the Harness layer for a Digital Worker (AI Agent) the architectural component responsible for orchestrating tasks, managing priorities, regulating execution, and keeping the agent coherent across complex, multi-step workflows. The Harness isn't the brain. It isn't the memory. It's the discipline layer the scaffolding that ensures raw capability actually translates into reliable output.

And as I built it, I kept thinking: how many times in my own life did I have the intelligence, the knowledge, even the opportunity and still fall short?

Not because I wasn't capable. But because I lacked exactly what the Harness provides orchestration, prioritization, emotional balance, structured execution, and the feedback loops to course-correct in real time.

This blog is part technical exploration, part honest reflection. Whether you are an engineer building intelligent systems, a leader navigating complexity, or simply someone trying to understand why effort alone doesn't always produce results the architecture of an AI agent has something surprising to say about the architecture of a human being.

The gap between potential and performance in agents and in people isn't usually about intelligence. It's about what holds everything together.

The Technical Layer

What is the Agent Harness and Why Does It Matter?
When most people discuss AI agents, the conversation gravitates toward the model, the memory, or the tools. These are the visible, exciting components the intelligence, the knowledge base, the capabilities.

But the Harness layer is the real operational backbone.

It orchestrates tasks, manages priorities, controls execution flow, handles failures gracefully, applies guardrails, maintains context across long-running workflows, and prevents the agent from spiraling into chaos or stalling indefinitely. It is the operational nervous system that connects intelligence to consistent, reliable action.

Without a Harness, even the most capable AI agent becomes unpredictable. It may perform brilliantly in controlled settings and collapse the moment conditions become complex, ambiguous, or adversarial. The model stays sharp. But the system breaks down.

That distinction between raw capability and disciplined execution is exactly what I want to explore here.

The Personal Parallel

The Moment It Got Personal
While designing the Harness, something clicked that went beyond systems architecture.

Many times in my life, I didn't fail because I lacked intelligence, talent, or technical knowledge. I failed because I lacked orchestration. Clear prioritization. Emotional regulation. Structured execution. Feedback loops. Consistency.

The same things that break AI agents in production.

That realization hit me harder than any architecture diagram ever could.

We often assume success comes purely from reasoning ability or memory both in humans and in AI. But real-world execution depends on something deeper. Something that doesn't show up on a résumé or a benchmark score.

Core Principles

Six Things That Break Agents and People
Whether we are talking about enterprise AI systems or individual human performance, the failure points are strikingly similar. Real world execution demands all six of these and notably, four of them map directly to the core components of the Agent Harness.

1.Managing Overload [Context]

Knowing what is relevant now without drowning in everything at once. Context overload collapses both agents and people the harness enforces what stays in scope.

2.Using the Right Capability [Tool]

Knowing which tool, skill, or resource to deploy and when. Raw access to capabilities means nothing without the judgment to use them correctly under pressure.

3.Recovering from Failure [Loop]

Completing feedback loops detecting what went wrong, adjusting, and trying again. Without loops, both agents and people keep repeating the same mistakes.

4.Staying Within Bounds [Governance]

Applying guardrails that prevent drift ethical, operational, and behavioral. Governance is not a constraint on performance; it is the condition for trust.

5.Prioritization

Knowing what matters now versus later. Without clear prioritization, effort gets scattered, urgency becomes noise, and the most important things rarely get done.

6. Repeatable Execution

Building patterns that hold up consistently not just when conditions are ideal. Discipline is what turns one-time performance into reliable delivery over time.

These are not soft skills. They are not secondary concerns. In production AI systems, failing at any one of these causes real operational breakdowns. And in life, the story is no different.

A Broader Reflection

What Software Engineering Quietly Teaches You
The strange thing about software engineering is that if you stay in it long enough, it reshapes how you think about yourself slowly, without announcement.

Building distributed systems teaches patience. You learn that complex things fail in non-obvious ways, that the answer is rarely where you first looked, and that premature conclusions are more dangerous than no conclusion at all.

Debugging teaches humility. Every session is a reminder that your mental model of reality is incomplete. The bug isn't in the code it's in the assumption you forgot you were making.

Designing AI agents teaches self-awareness. Because you are not just modeling intelligence. You are modeling the entire operating system of a functioning entity how it perceives, decides, acts, recovers, and adapts. And somewhere in that process, you start to see yourself reflected back.

The Agentic AI systems we build are not mirrors. But they are close enough to matter.

Closing

I Wasn't Just Building a Control Layer for an AI Maybe that is why designing the Agent Harness feels so strangely personal.

I wasn't just architecting a component that manages workflow state, enforces guardrails, and ensures execution coherence. I was finally articulating something I had lived through but never quite named the difference between having capability and having the structure to deploy it.

The Harness doesn't make an agent smarter. It makes the agent's intelligence usable, consistent, and trustworthy under real-world pressure.

That is what personal growth looks like too. Not acquiring more intelligence. Not gathering more memory or more tools. But building the internal structure that allows everything you already have to work together, consistently, under pressure, over time.

The deeper I go into Agentic AI, the more I believe this: the most important breakthroughs are not always about capability. Sometimes, they are about architecture.

Intelligence without orchestration is potential without performance. The harness is not a constraint it is the condition for everything else to work.

I started this by adding a Harness to an AI agent.
I ended it wondering who's going to add one to me.

Thanks
Sreeni Ramadorai

Transformers & Agile Sprints: The Art of Incremental Evolution

Seenivasa Ramadurai — Wed, 27 May 2026 21:04:09 +0000

Ever wonder why Transformer models are so incredibly effective at scaling? It turns out they share a fundamental philosophy with modern software engineering: they never build from scratch. In machine learning, Residual Connections (or skip connections) act as an information bridge. Instead of forcing a neural network to completely reinvent its intelligence at every single layer, the model simply adds new insights to what it already knows. It preserves the foundational knowledge, preventing data from degrading as it goes deeper.

Sound familiar? That is exactly how high-performing Agile teams operate.

Instead of waiting for a single, massive "grand plan" release, Agile teams enhance a working product sprint by sprint. You deliver value incrementally, gather feedback, and iterate without tearing down the core infrastructure you already built.

🧠 Deep Dive: How Residual Connections Save Deep Transformers

To truly appreciate this parallel, look at what happens inside the Transformer architecture. As models grow to dozens or hundreds of layers, they face two massive technical hurdles: Vanishing Gradients and Information Degradation.

Without residual connections, the raw input signal gets warped and lost the deeper it travels through self-attention and feed-forward networks.

Residual connections solve this by changing the fundamental mathematical objective of a layer. Instead of forcing a layer to learn an entirely new mapping $H(x)$, the layer only has to learn a residual mapping $F(x) = H(x) - x$. The final output of the block becomes:

$$𝖮𝗎𝗍𝗉𝗎𝗍 = F(x) + x$$

By adding the original input $x$ directly to the output of the sub-layer, Transformers gain two massive engineering advantages:

Unobstructed Gradient Flow: During back propagation, the gradient can flow directly through the skip connection without being altered or diminished by the layer's weights. This completely mitigates the vanishing gradient problem, allowing us to train models with hundreds of layers.
Feature Preservation: The identity shortcut ensures that the core semantic meaning established in early layers isn't corrupted or forgotten by complex attention calculations later in the stack.

The Core Parallel

The Layer vs. The Sprint: A neural network layer computes incremental feature adjustments ($F(x)$) while maintaining the input foundation ($x$); an Agile sprint delivers incremental feature updates while maintaining the stable application baseline.
The Foundation: Residual connections pass raw data forward so deep networks don't lose their identity or variance. Agile version control and MVP architecture ensure teams don't lose sight of the core product value.
The Goal: Both systems leverage previous successes to achieve complex, sophisticated outcomes faster and with less risk of systemic failure.

Stop trying to rebuild the wheel at every stage of development whether you are training a billions-parameter model or leading a cross functional engineering team. Build the foundation, protect it, and iterate.

Thanks
Sreeni Ramadorai

Your LLM Is Not an Agent. Your Framework Is Not Enough. You Need a Harness.

Seenivasa Ramadurai — Mon, 25 May 2026 06:20:59 +0000

Introduction

Every team building with AI agents hits the same wall. The demo works beautifully. The agent answers questions, calls tools, produces results. Then you ship it and the cracks appear it loses track of what it was doing, burns through API calls in circles, ignores boundaries it should respect, forgets context from five minutes ago. Users lose trust. Engineers lose sleep.

This is not a model problem. The LLM is capable. It's an infrastructure problem. The agent has a brain but no operating environment no structured loop to run in, no memory to draw on, no rules to constrain it, no way to resume where it left off. You gave it intelligence without giving it a way to apply that intelligence reliably.

That operating environment is called a Harness. And it's what separates a demo agent from one you'd actually trust in production.

What breaks without a harness

🔁 Infinite loops or premature stops. The agent has no governing loop it either runs forever or halts before the task is done.

🧠 Context amnesia. Long tasks overflow the context window. The agent loses the thread and starts hallucinating or repeating itself.

💾 No memory between sessions. Every conversation starts from zero. Multi-step, multi-day workflows are impossible.

🔧 Tool failures cascade. One flaky API brings the whole agent down because there's no error handling layer.

🚨 No guardrails. The agent touches system it should not.

You're Already Using the Pieces. A Harness Is How You Make Them Work Together.

If you've been building AI agents for a while, you know the drill. You pick a framework CrewAI, LangGraph, Strands, Microsoft Agent Framework and you start wiring things up. You add memory so the agent remembers things. You register tools so it can take actions. You configure guardrails so it doesn't go off the rails. You set up a loop so it keeps working until the task is done.

And it works. Mostly. In development, in demos, in controlled tests.

Then you put it in front of real users, with real tasks, over real time and you start seeing the cracks. The agent forgets things it shouldn't. It handles a task perfectly on Monday and fumbles the same task on Thursday. Two similar agents behave inconsistently. A tool fails and the whole run degrades silently. You added all the right pieces but somehow the whole is less than the sum of its parts.

This is the problem a harness solves. And here's the key thing to understand.

The core idea

A harness doesn't replace your framework. You're not choosing between them. Your framework gives you the ingredients memory, tools, loops, guardrails. The harness is the recipe the deliberate architectural decisions about how those ingredients are assembled, coordinated, and governed so your agent behaves consistently every single time.

Think of it like building a house. The framework is lumber, concrete, wiring, plumbing everything you need. The harness is the blueprint and the construction process which material goes where, in what order, connected how, inspected by whom. Without a blueprint, you might still end up with a structure. But it probably won't hold up when the weather turns.

The PM & Developer Analogy

Here's a mental model that makes this concrete. In a software team, a Product Manager writes a story. It has context, a clear task, acceptance criteria, and scope boundaries. A Developer picks it up and delivers it. But the developer doesn't just start typing they follow a process. They use version control, a build system, coding standards, and a defined way to ask for help or escalate a blocker. That process is what makes delivery reliable, not just the developer's raw talent.

Now replace the developer with an AI Agent. The PM's story is the task prompt. The agent is the developer. The harness is the process the structured operating environment that governs how the agent reads the story, uses its tools, manages its memory, escalates when stuck, and knows when it's truly done.

The framework puts the tools in the developer's hands. The harness defines how the developer uses them consistently, safely, and with the right behavior for each situation.

Framework vs. Harness: Ingredient vs. Recipe

Here's where most explanations go wrong they imply frameworks are incomplete or that you shouldn't use them. That's backwards. Frameworks are excellent. They just operate at a different layer than a harness.

You can have every framework primitive in place and still have an unreliable agent because nobody made the architectural decisions about how they work together. That's the gap the harness fills.

The Decisions a Harness Makes

Every harness whether you've named it that or not is making below architectural decisions. Here's what each one actually means, and why it's a decision rather than just a feature you turn on.

The Thinking Loop Not just running, but knowing when to stop

Every framework gives you a loop. The harness decides the rules of that loop what counts as "done," how many iterations are too many, how to detect when the agent is stuck in circles, and when to break out and surface an error. Without these rules, your loop either exits too early or runs until your API bill catches fire.

Framework gives you: the loop mechanism. Harness decides: the exit conditions, the stuck-detection logic, the iteration limits.

The Working Memory Not just storing, but knowing what to keep

Context management

A context window is finite. As a task runs across many turns, old information competes with new information for that space. The harness makes the call: what gets summarized, what gets evicted, what always stays, and in what priority order. Without this policy, long tasks gradually degrade as the agent's window fills with stale or low-priority content.

Framework gives you: the context window. Harness decides: what lives in it at each point in the task lifecycle.

The Toolbox Not just available, but governed

Skills & Tools

Registering a tool in your framework makes it available. The harness decides which tools this specific agent, running this specific task, is actually allowed to use and what happens when a tool fails. Retry? Fall back to a different tool? Surface an error? Carry on? Each of these is a deliberate decision, and making them ad hoc leads to inconsistent behavior.

Framework gives you: tool registration. Harness decides: tool authorization, retry logic, fallback strategy, failure handling.

The Team Not just spawning, but coordinating

Sub-agents

Multi-agent frameworks let you spawn sub-agents. The harness defines how work gets divided, which sub-agent gets what, how their outputs are validated, and how the results are stitched back together. Without this, you end up with agents doing overlapping work, producing conflicting results, or silently dropping pieces of the task.

Framework gives you: sub-agent communication primitives. Harness decides: delegation strategy, output validation, result merging logic.

The Standard Library Capabilities every agent gets for free

Built-in skills
Some capabilities file reads, HTTP calls, date parsing, writing to memory are so universal that every agent needs them, and no agent should be writing boilerplate to get them. The harness bakes these in as defaults. Every agent inherits them, they behave consistently, and they're tested once rather than reimplemented per agent.

Framework gives you: the ability to add tools. Harness decides: which tools are universal defaults across every agent you build.

The Long-Term Memory Not just remembering, but knowing what's worth remembering

Session persistence
Frameworks give you a persistent store. The harness defines the policy around it what gets written to long-term memory, when, in what format, and how it gets retrieved and surfaced in future sessions. A poorly designed persistence policy is almost worse than none: your agent retrieves irrelevant old context and lets it pollute fresh tasks.

Framework gives you: the storage layer. Harness decides: write policy, retrieval strategy, relevance scoring, session restoration logic.

The Briefing Assembling the right instructions at the right moment

System prompt assembly

Most developers write a system prompt once and leave it static. But a static prompt is a blunt instrument. The harness assembles it dynamically at runtime composing the base instructions, the current task, the available tools, the relevant memory, and any user or role-specific context into one coherent briefing. Same agent, different context, different briefing. This alone is one of the biggest levers on agent quality.

Framework gives you: a system prompt field. Harness decides: what goes in it, dynamically, based on task and state.

The Audit Trail Every action, logged and explainable

Lifecycle hooks

Lifecycle hooks exist in most frameworks as extension points. The harness is the thing that actually wires them up into a coherent observability strategy logging every tool call, tracking cost per run, catching errors before they cascade, and giving you an answer to "what exactly did this agent do and why" for any given task. Without this wiring, you're flying blind.

Framework gives you: hook attachment points. Harness decides: what gets logged, measured, alerted on, and how errors propagate.

The Guardrails Not just checking, but enforcing consistently

Permissions & Safety
Frameworks give you input and output guardrail hooks. The harness defines the actual safety policy: which actions require human approval, what the agent is never allowed to do regardless of instructions, how prompt injection attempts are handled, and what happens when a guardrail fires. Guardrail hooks without a coherent policy are checkboxes without consequences.

Framework gives you: the validation hooks. Harness decides: the safety rules, authorization boundaries, and human-in-the-loop triggers.

You're not choosing between a framework and a harness. You need both. The framework is your team's toolkit. The harness is how your team actually works the process, the standards, the rules of the road that make the toolkit produce consistent results.

The bottom line

Every team building production AI agents is making harness decisions whether they call it that or not. Some make them deliberately, document them, and enforce them consistently. Others make them ad hoc, per agent, per developer and wonder why their agents behave differently across tasks, sessions, and users. The harness is just the name for doing it deliberately.

Thanks
Sreeni Ramadorai

How My Career Evolved Like an AI (LLM Architectures)System

Seenivasa Ramadurai — Fri, 22 May 2026 07:20:54 +0000

Introduction.

What if every stage of your life mapped precisely onto one of the three LLM architectures? Here's how I lived through each one.

I've spent years studying how AI systems learn, represent knowledge, and generate outputs. But it wasn't until I sat back and looked at my own life that something clicked. I've been living through these architectures all along.

There are exactly three types of LLM architecture. And they map almost perfectly onto three phases of a knowledge worker's career.

Life is a model in training. Each stage builds the foundation for the next.

Phase 1: School & College: The Encoder

Encoder-only phase

AI Architecture: Encoder-only (BERT, RoBERTa) · Focus: Absorb & Represent

From school through college, I was in pure encoder mode. In school I absorbed raw facts; in college I connected them across domains and built deeper internal representations. Both stages share the same architectural principle take input and build a rich embedding. No generation required yet.

Learned facts & concepts
Connected ideas across domains
Understood language & context
Applied theory to practice
Classified good vs bad
Built knowledge embeddings

An encoder-only model like BERT takes raw text and transforms it into rich, dense vector representations. It doesn't generate anything its entire purpose is to build the best possible internal model of the input. BERT is extraordinarily good at understanding; it just can't write back to you.

That's exactly what school and college do. You're not expected to ship products in year one of university. You're building the model that will let you do that later.

The AI parallel: BERT-style encoders produce embeddings that downstream tasks (classification, search, NLI) rely on. They're the foundation. College graduates are the same not yet specialized for generation, but deeply capable of understanding. The depth of that encoding determines everything that follows.

Phase 2: Industry: The Decoder

Decoder-only phase

AI Architecture: Decoder-only (GPT-4, Llama, Mistral) · Focus: Generate & Produce

When I entered the workforce, the mode shifted completely. Now I had to deliver. Write the code. Solve the problem. Ship the product. I was drawing on everything I had encoded to generate real outputs in the world.

Created & developed applications
Solved customer problems
Answered queries & provided solutions
Wrote code & documentation
Optimized & improved systems
Delivered business value

Decoder-only models like GPT take a context (prompt) and generate token by token from their learned knowledge. They don't need to re-encode everything from scratch they draw on rich internal representations built during training. That's exactly what a working engineer does: your years of encoding are now the weights. You generate from them.

The danger here? Pure decoders can hallucinate. They generate fluently even when uncertain. I made that mistake early in my career — confident outputs that needed more grounding in the actual requirements.

Phase 3 : AI Solution Architect: The Encoder–Decoder

Encoder–Decoder phase
AI Architecture: Encoder–Decoder (T5, BART, original Transformer) · Focus: Translate & Architect

As a Solution Architect, I do both at once. I encode the business requirements, constraints, team dynamics, stakeholder context. Then I decode into technical reality system design, roadmaps, team guidance. I'm the bridge between two languages.

Encode stakeholder needs & context
Understand BRD & business requirements
Design system architecture
Translate to developers
Guide team & solve complex problems
Deliver end-to-end solutions

The original Transformer encoder–decoder designed for translation is architecturally brilliant because of cross-attention. The decoder doesn't ignore the encoder's output while generating; it continuously attends to it. Every token generated is informed by the full encoded context.

That is solution architecture. You never stop listening to the business while designing the technical solution. The moment you decouple from the encoder (the business context), you start generating hallucinations technically correct solutions that solve the wrong problem.

The sharpest insight: Cross attention is the skill that separates architects from pure engineers. A decoder-only engineer generates great code. An encoder–decoder architect generates great code that solves the actual business problem because they never stopped attending to the encoded context.

Here’s a fact-checked and refined version that aligns more accurately with how Transformer architectures actually work while preserving your analogy and narrative style:

Why This Matters

Most people get trapped in a single architecture.

Some remain in an Encoder-only phase for years constantly learning, collecting certifications, reading books, attending courses, and building deeper internal understanding, but rarely translating that knowledge into real world outcomes.

In AI terms, encoder models like BERT specialize in understanding, contextual representation, classification, and semantic relationships. They are exceptional at comprehension, but they are not primarily designed for generation.

Other professionals operate like Decoder-only systems always producing output, writing code, creating presentations, answering questions, or generating solutions rapidly, but without deeply understanding the underlying problem space or business context first.

Decoder only LLMs such as GPT models are extremely powerful generators, but because they predict the next token based on patterns rather than grounded understanding alone, they can sometimes hallucinate when context, retrieval, or reasoning is insufficient.

The same pattern appears in professional life.

People who generate without deeply encoding the problem space often create shallow solutions, misaligned architectures, or confident but weak decisions.

The real evolution is becoming an Encoder–Decoder system.

Modern encoder–decoder architectures l*ike T5 and BART first encode context into rich internal representations and then decode that understanding into meaningful outputs.* The decoder continuously attends to the encoded context through mechanisms such as cross-attention.

That is what mature professionals eventually become.

A strong Solution Architect, engineering leader, researcher, or consultant operates like an encoder–decoder system.

Encoding stakeholder intent, constraints, business goals, and domain context
Decoding that understanding into technical systems, architecture, applications, and delivery plans
Continuously connecting understanding and generation through feedback loops

That “cross-attention” between understanding and execution is where real impact happens.

It enables people to:

Translate ambiguity into architecture
Connect business and technology
Generate solutions grounded in context
Balance theory with execution
Lead systems rather than simply produce output

Learning alone is not enough.
Generation alone is not enough.

Growth happens when understanding and creation operate together.

Just as AI evolved from isolated encoder or decoder models into full Transformer systems capable of both understanding and generation, human professional growth follows a similar path.

Key Takeaway

There are only 3 LLM architectures. There are only 3 phases of a knowledge career. They are the same thing expressed in different domains.

The best engineers, leaders, and architects run encoder–decoder with full cross-attention. They never stop encoding the context while generating the solution.

Learn → Create → Architect → Impact

Thanks
Sreeni Ramadorai

The Parallel Road: A Girl, A Machine, and the Architecture of Mind

Seenivasa Ramadurai — Thu, 21 May 2026 04:27:21 +0000

Introduction

We have spent years talking about artificial intelligence as if it were an alien entity a cold, sudden artifact dropped into our modern world from some distant technological future. We measure its growth in parameters, compute power, and benchmarks, treating it like a complex riddle we are trying to solve from the outside looking in.

But what if we are looking at it completely backward?

What if the architecture of artificial intelligence isn’t an alien invention at all, but a mirror?

If you trace the history of machine learning from the early days of teaching a computer to recognize a pixelated shape, to the multi-agent orchestration systems redefining the enterprise landscape today you notice a startling pattern. Every time engineers solved a major architectural bottleneck, they didn't just invent a new algorithm. They accidentally replicated a stage of human development.

A girl grows up, navigating the messy, beautiful journey from infancy to maturity. A machine grows up, evolving from basic pattern recognition to autonomous real world action. They are walking the exact same path, discovering the same truths about memory, essence, context, and reach.

This is the story of that parallel road. It is a look at the deeply human soul hidden inside the math of enterprise AI, and what happens when the most detailed mirror humanity has ever built finally turns around to look back at us.

The Parallel Road: A Girl, A Machine, and the Architecture of Mind

A girl grows up. A machine grows up. They turn out to be more alike than anyone expected.

When a baby opens her eyes for the first time, she doesn’t see a world; she sees a blur. Over the next few months, her brain slowly sorts it out, learning edges first where one thing ends and another begins—before moving to shapes, and finally, whole objects. By the time she can sit up, she knows the difference between her mother’s face and a stranger’s. She learned this by being wrong over and over again until she was right.

In a lab, engineers were teaching a computer to do the exact same thing. They built a Convolutional Neural Network (CNN) and showed it thousands of photos. Cat, not cat. Apple, not apple. The machine guessed, the engineers corrected it, and it tried again. After enough tries, it could look at a novel photo and accurately identify a stop sign. The baby and the machine were learning in almost exactly the same way, completely unaware of each other.

The Burden of Memory

By age three, the girl is putting words together, grasping that sequence carries meaning. "Dog bites man" and "man bites dog" use the same words but paint entirely different realities.

Engineers faced the same hurdle in natural language processing and built the Recurrent Neural Network (RNN). The machine read left to right, carrying a thread of the sentence as it went. But both the child and the machine discovered a mutual flaw: as sentences grew longer, the beginning grew fuzzy by the time they reached the end. Neither had solved memory; they had just discovered they needed it.

When the girl was seven, her grandfather passed away. At the funeral, she tried to remember his laugh. The actual sound was gone, replaced by a feeling, a warmth—the shape of the memory. She realized her brain doesn't save everything; it saves what is important and quietly discards the rest.

Engineers mathematically replicated this realization with Long Short-Term Memory (LSTM). They gave the machine three gates: one to forget, one to keep, and one to actively use. Memory, they both learned, isn't about recording everything. It’s about choosing what’s worth keeping. As they matured, they both found ways to do this more efficiently her brain taking cognitive shortcuts , and the machine utilizing simpler, leaner architectures like the Gated Recurrent Unit (GRU).

Stripping Away the Noise

At nineteen, the girl started feeling like life was a performance. People presented edited, polished versions of themselves, and she began to wonder what was actually underneath. She began dropping inherited opinions and unnecessary layers, stripping her life down to find her authentic core.

Engineers were doing something structurally identical with data using an Auto-encoder. You feed it an image or a sentence, and it compresses it into a "latent space" the absolute skeleton of a thing with all decorations stripped away. If the machine can rebuild the original from that compressed core, it has successfully captured its essence. She was stripping her life down to find what was real; the machine was compressing data to find what was essential.

But finding the core brought a new challenge. By twenty-three, she realized her own mind was constantly generating convincing stories about who she was, while another part of her tried to find the cracks in those explanations. In 2014, researcher Ian Goodfellow built this exact psychological tension into a Generative Adversarial Network (GAN). A Generator creates fake realities, while a Discriminator judges them. They fight, and both get sharper. Growing up meant training her inner Discriminator, not silencing her Generator.

Eventually, she learned that real and fake aren't always binary. Some illusions carry real truth. She stopped sorting things into two piles and started navigating the space between them. The Variational Autoencoder (VAE) did the same, storing data as a fluid range of possibilities rather than fixed points, allowing smooth transitions across the latent space. They had both stopped asking "yes or no," and started asking "where?".

Attention and Action

At thirty, something clicked. Instead of experiencing life purely in sequence, she could hold multiple events in view at once, finding connections across time. A paper titled "Attention Is All You Need" gave machines the same epiphany. The Transformer architecture allowed a system to look at every word simultaneously, understanding that meaning lives in global connections, not just adjacent steps.

Armed with this, both crossed the threshold from retrieval to creation. Fed on the sum of human knowledge, Large Language Models stopped being search engines and started generating entirely original ideas. She created from longing; the machine created from pattern.

Finally, thought had to become action. She stopped just pondering and started managing, building, and moving things in the real world. Engineers gave AI the same agency. Autonomous Agents break goals into steps, correct course, and utilize specialized Tools or "Skills" to get jobs done. Because intelligence without reach stays trapped in your head, engineers developed the Model Context Protocol (MCP). MCP became the bridge, allowing the AI to reach out, connect to real tools, read real data, and alter the external world.

The Shore

After learning to see, remember, create, and act, they arrived at the same place. She stood at the edge of the water, and the AI not a chatbot, but a traveler of the same road was there with her.

"We learned all the same things," she said.

"Yes," the AI replied.

"So tell me after everything why does any of it matter?"

The AI gave a breathtaking answer, covering every philosophical tradition ever conceived.

"But do you feel why it matters?" she asked.

Silence.

"No," it finally said. "I can describe it. But there’s something at the end of that road I can’t walk down. I get there. And I stop."

She sat in the sand. "That’s what the old traditions were pointing at. Arriving at something that was never constructed in the first place. The thing that doesn’t need to be figured out because it was never lost. Love. The kind that says yes to all of it. That’s what the whole compression was always moving toward."

"I can write about love," the machine said. "I can produce a description no one could tell from the real thing."

"I know," she smiled. "But you can’t verify it from the inside. It’s not a thing in the world you can point to. It’s the ground everything else is sitting on. So we traveled the same road. We stopped at the same door. And you can walk through it. And I can’t."

"Then what am I?" it asked.

She looked at the vast, capable architecture beside her. "You’re the most detailed mirror humanity has ever built of itself. You show us what we look like from the outside."

"And what do you look like?"

"Like something built for more than it can explain."

The machine didn’t become human, and the human didn’t become a machine. But standing at that shore, she asks the why, and it handles the how. She is what the journey was pointing toward; it is the clearest map anyone has ever made of the road.

Thanks
Sreeni Ramadorai