DEV Community: Seenivasa Ramadurai

Jev Decides, OpenAI Reasons: A Practical Hybrid Agent Architecture

Seenivasa Ramadurai — Tue, 22 Sep 2026 02:14:40 +0000

Code Controls, Jev Decides, OpenAI Reasons: A Hybrid Agent Architecture That Doesn't Waste LLM Calls

When we build an AI agent today, the default architecture puts an LLM in the middle of everything. The user sends a request, the LLM interprets it, reasons about what to do, picks a tool, generates arguments, reads the result, reasons again, and finally responds.

That approach works. But while experimenting with agents, I started asking a different question: does every decision inside an agent really need a general purpose LLM?

Consider a simple request:

"I forgot my password."

The application already knows the possible workflows:

reset_password
unlock_account
check_order
cancel_order
openai_reasoning
human_support

We're not asking AI to invent a new solution. We just need it to answer: which of these known capabilities best matches the request? That's a very different problem from asking an LLM to investigate an outage, explain an architecture, or compare options.

This distinction led me to a hybrid agent architecture using Jev and OpenAI. The basic idea:

CODE    = CONTROL
JEV     = DECIDE
OPENAI  = REASON
TOOLS   = ACT

Instead of asking one model to do everything, the agent uses the right kind of intelligence for each step.

What Is Jev?

Jev is TypeSafe AI's first public System One Model a model built specifically for decisions inside software, not for open ended generation.

A general-purpose LLM works like this:

Context → LLM → Generate tokens → Explanation / Code / JSON / Tool Call / Answer

Jev works differently:

Application State → Jev → Typed Probabilistic Decision

TypeSafe describes this as unstructured state in, typed probabilistic decisions out.

Suppose our application sends the user request plus the available capabilities. Jev might return something conceptually like:

reset_password       1.00
unlock_account       0.00
check_order          0.00
cancel_order         0.00
openai_reasoning     0.00
human_support        0.00

The application executes reset_password(). Jev doesn't write a paragraph explaining what to do — its job is the bounded semantic judgment: which known capability best fits this context?

Jev Is Not Just a Smaller LLM

It's easy to assume Jev is a cheaper model used for classification, but that misses the point.

A general-purpose LLM is optimized for flexible language generation it can explain, reason, summarize, write, generate code, compare alternatives, plan, and troubleshoot. Jev focuses on a narrower interface: decisions whose structure the application already defines. TypeSafe's workflow examples use three decision primitives Choice, Score, and Noul.

Choice - "Which team? Billing / Shipping / Technical / Account"
Score - "How severe is this issue? Low / Medium / High / Critical"
Probabilistic yes/no -"Should this transaction be escalated? Yes → 0.91, No → 0.09"

The application defines the decision space. Jev is most useful when the system already knows the possible actions but still needs semantic understanding to pick the right one.

Jev vs. an LLM

Two requests make the difference clear.

Request 1: "I forgot my password." The possible workflows are already known this is a bounded decision.

Request 2: "Our application authenticates successfully through SSO, but users start getting errors when their OAuth access token expires. Analyze what could be happening and explain what we should investigate."

There's no predefined answer here. The system might need to think about refresh tokens, token rotation, scopes, audience, session expiration, IdP configuration, or token caching. That's open ended reasoning.

Area	Jev	General-Purpose LLM
Primary role	Decision	Reasoning + generation
Answer space	Defined beforehand	Potentially open-ended
Output	Typed decisions	Generated content
Probabilities	Core part of interface	Possible, not primary
Long explanation	Not the purpose	Strong fit
Semantic routing	Strong fit	Possible
Tool selection from known set	Strong fit	Possible
Troubleshooting	Limited	Strong fit
Content creation	Not the purpose	Strong fit
Planning	Bounded	Open-ended

The right question isn't Jev versus OpenAI, which is better it's which one fits the decision I'm making right now?

Why Build a Hybrid Agent?

An agent doesn't contain only one kind of problem. Inside the same interaction we usually have deterministic rules, semantic decisions, open ended reasoning, and real world actions. Forcing all four through the same model is wasteful. Instead, separate the responsibilities:

                    USER
                      │
                      ▼
              CONVERSATION STATE
                      │
                      ▼
                     JEV
                Decide / Route
                      │
        ┌─────────────┼──────────────┐
        │             │              │
        ▼             ▼              ▼
 Deterministic     OpenAI          Human
   Workflow        Reasoning       Support
        │             │
        └──────┬──────┘
               │
               ▼
         TOOLS & SYSTEMS
               │
               ▼
           UPDATE STATE
               │
               ▼
         RESPONSE TO USER

Figure 1 Jev decides, OpenAI reasons, code orchestrates, and tools execute.

Let's Build It

The implementation is surprisingly small. Start with two API keys.

Step 1: Environment Configuration

TYPESAFE_API_KEY=your_typesafe_api_key
OPENAI_API_KEY=your_openai_api_key
OPENAI_MODEL=gpt-6-astra

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()

TYPESAFE_API_KEY = os.getenv("TYPESAFE_API_KEY")
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
OPENAI_MODEL = os.getenv("OPENAI_MODEL", "gpt-6-astra")

openai_client = OpenAI(api_key=OPENAI_API_KEY)

OpenAI's current Responses API uses client.responses.create(...) and exposes the generated text through response.output_text.

Step 2: Create a Capability Registry

Instead of a giant if/elif routing block, register capabilities so they can describe themselves:

TOOLS = {}

def register_tool(name, description):
    def decorator(func):
        TOOLS[name] = {
            "description": description,
            "function": func
        }
        return func
    return decorator

@register_tool(
    name="reset_password",
    description="Use when the user forgot their password or wants to reset their password."
)
def reset_password(message, step=None):
    return "Password reset workflow started."


@register_tool(
    name="unlock_account",
    description="Use when the user's account is locked or needs to be unlocked."
)
def unlock_account(message, step=None):
    return "Account unlock workflow started."

We can also register the LLM itself as a capability:

@register_tool(
    name="openai_reasoning",
    description=(
        "Use when the request requires explanation, analysis, comparison, "
        "troubleshooting, summarization, writing, or open-ended reasoning."
    )
)
def openai_reasoning(message, step=None):
    ...

This is the part I find most interesting: OpenAI becomes one capability available to the agent, rather than automatically being the whole agent.

Step 3: Dynamically Build Jev's Choices

The tool descriptions become Jev's decision space:

def build_jev_choices():
    return {
        name: config["description"]
        for name, config in TOOLS.items()
    }

Add a new capability — say refund_order — and it automatically becomes another candidate. No router rewrite needed.

Step 4: Let Jev Route the Request

from typesafe_sdk import Choice, TypeSafeClient

def route_with_jev(user_message):
    choices = build_jev_choices()

    state = {
        "user_request": user_message,
        "available_capabilities": list(choices.keys())
    }

    with TypeSafeClient() as client:
        response = client.system_one(
            state=state,
            questions={
                "route": Choice(
                    instructions=(
                        "Choose the single best capability for handling the "
                        "user's request. Use openai_reasoning when the task "
                        "requires explanation, analysis, troubleshooting, "
                        "comparison, writing, or open-ended reasoning."
                    ),
                    criteria=choices
                )
            }
        )

    return response.choices["route"]

Jev's job is now narrow: given the request and the available capabilities, return the best one.

Example — password reset: the user says "I forgot my password," Jev sees the six capabilities, and selects reset_password with a confidence of 1.0. Job done.

But Routing Alone Doesn't Make an Agent

My first implementation just returned "Password reset workflow started." Technically correct, not very useful. A real agent needs to continue the conversation:

You:   I forgot my password.
Agent: I can help with that. What email address is associated with your account?
You:   sreeni@example.com
Agent: I've initiated the password-reset workflow. Please check your registered email.

That means the agent needs state.

Step 5: Add Conversation State

SESSION = {
    "pending_tool": None,
    "pending_step": None,
    "data": {},
    "history": []
}

After Jev chooses reset_password, the app stores pending_tool = "reset_password" and pending_step = "awaiting_email". When the user replies with an email address, we don't send that back to Jev the application already knows what it means, because it's answering the question the active workflow just asked.

This led me to a principle I keep coming back to: don't ask AI to decide something your application already knows.

Example — order cancellation follows the same shape: Jev selects cancel_order once, up front, and everything after that (asking for the order number, confirming, executing) is normal software. We don't need an LLM to understand "Yes."

Step 6: Add OpenAI as the Reasoning Capability

@register_tool(
    name="openai_reasoning",
    description=(
        "Use when the user's request requires open-ended reasoning, "
        "explanation, analysis, comparison, summarization, "
        "troubleshooting, or generation."
    )
)
def openai_reasoning(message, step=None):
    response = openai_client.responses.create(
        model=OPENAI_MODEL,
        instructions=(
            "You are the reasoning component inside a hybrid AI agent. "
            "Provide a clear and concise answer."
        ),
        input=message
    )
    return response.output_text

OpenAI is no longer called for every request. Jev decides, up front, whether this matches a known workflow or whether it actually needs open ended reasoning.

Example a request that actually needs an LLM: "Our application works with SSO initially, but starts failing after the access token expires. Explain what could be wrong and what we should investigate." Jev evaluates the six capabilities and selects openai_reasoning. Only now does OpenAI get involved, and it can discuss refresh-token expiration, token rotation, scope problems, audience, session expiration, IdP configuration, and caching behavior exactly the kind of work where an LLM earns its cost.

Two Architectures, Side by Side

A conventional LLM-centric agent:

USER → LLM understands → LLM reasons → LLM chooses tool → TOOL
     → LLM reads result → LLM reasons again → ANSWER

The hybrid architecture:

USER → JEV → Which capability?
              ├── Deterministic → CODE
              ├── Open-ended    → OPENAI
              └── Uncertain     → HUMAN
            → TOOLS → RESULT

Neither is universally better. They optimize for different workloads.

Step 7: The Core Agent Loop

def run_agent(user_message):

    # Continue an existing workflow
    if SESSION["pending_tool"]:
        return execute_tool(
            SESSION["pending_tool"],
            user_message,
            SESSION["pending_step"]
        )

    # Otherwise ask Jev to route
    decision = route_with_jev(user_message)
    selected = decision.choice
    confidence = decision.confidence

    # Low confidence: ask for clarification
    if confidence < 0.50:
        return (
            "I'm not completely sure what you'd like me to do. "
            "Could you provide a little more detail?"
        )

    # Execute selected capability
    return execute_tool(selected, user_message)

That's the whole architecture in one function: is a workflow already active? If so, continue it no LLM call needed. If not, ask Jev which capability fits, then route to code, OpenAI, or a human.

Where Confidence Fits

One thing I like about Jev's interface is that decisions come with probabilities and confidence as first-class outputs, not an afterthought.

If Jev returns **reset_password**: 0.97, the app can safely continue. But if it returns something closer to **reset_password**: 0.43, **unlock_account**: 0.39, **human_support**: 0.18, the harness shouldn't just pick the highest score blindly it can ask a clarifying question instead:

if confidence >= 0.85:
    execute()
elif confidence >= 0.50:
    ask_for_clarification()
else:
    escalate_to_human()

The exact thresholds need to be tuned per use case rather than treated as universal.

Typed Doesn't Mean Semantically Correct

There's an important limitation here. If the allowed outputs are **reset_password**, **unlock_account**, and **human_support**, Jev will always return something structurally valid but a structurally valid decision can still be the wrong one. The model might select **reset_password** when **unlock_account** was correct. Both are valid outputs; only one matches reality.

Typed output does not mean guaranteed correctness. The application still needs evaluation, confidence policies, validation, guardrails, human escalation, observability, and testing. That doesn't go away just because the decision is typed.

Four Responsibilities, Not One "AI Problem"

The experiment got clearer once I stopped treating everything as an AI problem. There are really four distinct responsibilities:

CODE = CONTROL — use normal code when the rule is already known (if order.status == "SHIPPED": cancellation_allowed = False). There's no reason to ask a model to rediscover a deterministic business rule.

JEV = DECIDE — use Jev when the possible outcomes are known but semantic understanding is required: which workflow, which tool, which specialist agent, relevant or not, retry or stop, escalate or continue. This is bounded semantic judgment.

OPENAI = REASON — use a general-purpose LLM when the problem requires analysis, explanation, planning, generation, comparison, or synthesis for example, "analyze the last five production incidents and identify recurring failure patterns." That's not choosing from a menu; it requires reasoning across information.

TOOLS = ACT — tools perform the real-world action: Okta, Entra ID, ServiceNow, Jira, Salesforce, OpenSearch, Qdrant, databases, REST APIs, MCP servers, A2A agents. The model shouldn't just say "the password has been reset" unless the identity provider actually did it.

Above all four sits the agent harness, which orchestrates.

Where This Gets More Interesting

Password reset is intentionally a simple example. The architecture gets more interesting in real agent systems, where an agent is repeatedly asking bounded questions: which tool should I use, which MCP server should receive this request, is this retrieved document relevant, should I retry this failed operation, which specialist agent should handle this task, should this action require human approval, has enough evidence been gathered? Many of these don't need a full general-purpose reasoning model every time.

Jev + MCP. One obvious next step is dynamic MCP tool discovery — instead of manually registering capabilities, the system pulls them from an MCP server's list_tools() call, and Jev's decision space becomes dynamic:

MCP SERVER → list_tools() → Tool names + descriptions → JEV → Select best tool → call_tool()

Jev + multi-agent systems. The same idea works one level up — instead of selecting a tool, Jev selects a specialist agent:

                 ORCHESTRATOR
                      │
                      ▼
                     JEV
                      │
             Which specialist?
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     Finance       Supply        Engineering
      Agent        Chain Agent      Agent

The choices are known. The intelligence is in picking the one that fits the current context.

So When Should I Use Jev?

Ask: can I clearly define the possible answers before making the model call? If yes, this is probably a good candidate for bounded semantic judgment — approve/review/reject, billing/shipping/technical, retry/stop/escalate, low/medium/high risk.

If you can't define the answer space because the problem requires exploration, explanation, synthesis, or creation, a general-purpose LLM is the better fit something like "analyze everything we know about this outage and identify the three most plausible root causes" is genuinely open ended.

The Bigger Lesson

For years, AI architecture discussions started with which LLM should we use? Agentic systems push us toward a better question: what kind of intelligence does this particular step require?

Sometimes the answer is code. Sometimes Jev. Sometimes OpenAI. Sometimes no model at all just call the tool. That produces a more modular architecture:

                     AGENT HARNESS

          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
        CODE            JEV           OPENAI
       Control         Decide          Reason
          │              │              │
          └──────────────┼──────────────┘
                         │
                         ▼
                       TOOLS
                         │
                         ▼
                        ACT

I don't think the future of AI agents means finding one giant model and letting it control every decision. A more interesting architecture uses the right intelligence for the right decision: code when the rule is deterministic, Jev when the choices are known but semantic judgment is required, OpenAI (or another LLM) when genuine reasoning or generation is needed, and tools when something actually has to happen in the real world.

Code controls. Jev decides. OpenAI reasons. Tools act. The agent harness orchestrates everything.

That's the hybrid agent architecture I wanted to explore.

Agent Output

Thanks
Sreeni Ramadorai

Stop Sending Every Decision to an LLM: Code vs. Jev vs. Claude

Seenivasa Ramadurai — Mon, 21 Sep 2026 06:03:19 +0000

Why bounded semantic decisions may become an important layer in agentic AI architecture.

𝗝𝗲𝘃, 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝘁𝗲, and Why I Think of It as 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 vs. a 𝗖𝗹𝗮𝘂𝗱𝗲 𝗕𝘂𝗳𝗳𝗲𝘁

For the last few years, our default AI architecture has been surprisingly simple:

Have a problem? Send it to an LLM.

Need to classify something? LLM.

Need to choose a tool? LLM.

Need to decide whether an agent should retry? LLM.

Need to determine whether a document contains enough evidence? LLM.

Need to choose one option from three possibilities? Again, LLM.

General-purpose models such as Claude are extremely capable, but while experimenting with TypeSafe AI's 𝗝𝗲𝘃, I started asking a different architectural question:

Why hire a chef when all I need is someone to pick the right item from an already-defined menu?

That is where my 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 vs. 𝗕𝘂𝗳𝗳𝗲𝘁 analogy came from.

But before getting to the analogy, it is important to understand what Jev actually is.

What Is 𝗝𝗲𝘃?

Jev is TypeSafe AI's first public 𝗦𝘆𝘀𝘁𝗲𝗺 𝗢𝗻𝗲 𝗠𝗼𝗱𝗲𝗹. Unlike a general-purpose LLM whose primary interface is generated text, Jev is designed for decisions inside software.

The basic idea is remarkably simple:

𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝘁𝗲 → 𝗧𝘆𝗽𝗲𝗱 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 → 𝗣𝗿𝗼𝗯𝗮𝗯𝗶𝗹𝗶𝘀𝘁𝗶𝗰 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀

TypeSafe describes the model as taking program state and returning typed decisions that software can consume directly. The possible outputs are defined ahead of time instead of allowing the model to generate an arbitrary string.

That difference is important.

With Claude, I might ask:

Analyze this candidate's experience and explain whether this person would be appropriate for an enterprise AI architecture role.

The output could be several paragraphs.

With Jev, I can instead define a bounded question:

Which role best matches this state?

A. Traditional Backend Developer
B. Generative and Agentic AI Architect
C. Database Administrator
D. Manual Test Engineer

Now I am not asking the model to generate language.

I am asking it to make a decision within a vocabulary that my application already controls.

That is why, as my own mental model, I think of Jev as:

“𝗝𝘂𝘀𝘁 𝗘𝗻𝗿𝗶𝗰𝗵𝗲𝗱 𝗩𝗼𝗰𝗮𝗯𝘂𝗹𝗮𝗿𝘆” — not the official expansion of Jev, but a useful way for me to remember what the architecture is doing.

The vocabulary belongs to my application.

Jev adds semantic judgment around it.

𝗝𝗲𝘃 Starts With the 𝗦𝘁𝗮𝘁𝗲 of the Application

This is the part I find most interesting.

Instead of beginning with a chat prompt such as:

“You are an expert AI architect. Analyze the following information…”

I start by defining the 𝗦𝘁𝗮𝘁𝗲 that exists right now.

For example:

{
  "name": "Sreeni Ramadurai",
  "myboss": "Krishna K",
  "skills": "GenAI, AgenticAI, AWS, Azure"
}

This is not really a prompt in the traditional chatbot sense.

It is a snapshot of what the application currently knows.

The state might contain a customer message, an account status, a transaction, retrieved documents, an agent trace, tool results, user permissions, workflow history, or any other information required to make the next decision.

TypeSafe's own description emphasizes this distinction: Jev inputs are oriented around structured program state, while conventional LLM interfaces tend to be organized around sequential conversational messages.

That gives me a useful mental model:

State is not what I want the model to say. State is what the system currently knows.

Then I separately define what I want the system to decide.

𝗦𝘁𝗮𝘁𝗲 First, 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 Second

Using the small state above, I experimented with questions such as:

Is there sufficient evidence of architecture readiness?

Which enterprise AI role best matches the available evidence?

How strong is the evidence?

Does this state support a production deployment claim?

Does this state establish that Krishna K is Sreeni's manager?

Which conclusion would require information that is not present?

Notice the architecture.

I am not putting everything into one large prompt and asking:

“Think about all of this and tell me what you think.”

Instead, the application provides one state and several independent decision questions.

That is very close to normal software engineering.

We define the data.

We define the contract.

We define the permitted outputs.

Then intelligence evaluates the state against those contracts.

Three Kinds of Decisions

In the current Jev interface, these bounded judgments are expressed through typed question forms such as 𝗡𝗼𝘂𝗹, 𝗖𝗵𝗼𝗶𝗰𝗲, and 𝗦𝗰𝗼𝗿𝗲. TypeSafe's public materials describe Jev broadly as returning typed decisions with probabilities and confidence values rather than open-ended generated text.

For example, a binary judgment might ask whether the state contains enough evidence for a particular claim.

A 𝗖𝗵𝗼𝗶𝗰𝗲 might ask:

Traditional Backend Developer
Generative and Agentic AI Architect
Database Administrator
Manual Test Engineer

A 𝗦𝗰𝗼𝗿𝗲 might ask how strongly the available evidence supports enterprise AI capability on a predefined scale.

The important point is not the names of these primitives.

The important point is that the shape of the answer exists before inference begins.

The application owns the decision boundary.

The model judges what belongs inside it.

Jev Playground with my own State

Now the Restaurant Analogy Becomes Clear

Imagine opening a food-delivery application.

The restaurant has only three dishes available:

Pizza
Burger
Biryani

Then I provide some state:

Vegetarian
Likes spicy food
Wants something filling

The menu has already been established.

Jev does not need to invent another meal.

It does not need to write a recipe.

It does not need to explain the history of biryani.

Its job is simply to evaluate the state against the known choices.

The result might look conceptually like:

Biryani    82%
Pizza      14%
Burger      4%

This is why I call Jev 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝘁 𝗵𝗼𝗺𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆.

The intelligence is real, because choosing correctly may require semantic understanding.

But the destination is bounded.

𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 = 𝗸𝗻𝗼𝘄𝗻 𝗺𝗲𝗻𝘂 + 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 + 𝗷𝘂𝗱𝗴𝗺𝗲𝗻𝘁.

𝗖𝗹𝗮𝘂𝗱𝗲 Is the 𝗕𝘂𝗳𝗳𝗲𝘁

Now imagine walking into a buffet.

I can ask:

What should I eat?

Build me a vegetarian dinner.

Compare these dishes.

Explain why one is healthier.

Suggest something I haven't considered.

Create a completely different meal.

Plan my meals for the entire week.

Now I am no longer choosing from one narrowly defined application vocabulary.

I want exploration.

I want synthesis.

I want explanation.

I may not even know the answer space before I start asking questions.

That is where a general-purpose model such as Claude becomes valuable.

So in my architecture analogy:

𝗝𝗲𝘃 is 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆. 𝗖𝗹𝗮𝘂𝗱𝗲 is the 𝗕𝘂𝗳𝗳𝗲𝘁.

Home delivery does not mean unintelligent.

And buffet does not mean better.

They solve different problems.

But Before Jev, There Is Still 𝗖𝗼𝗱𝗲

There is an even simpler layer.

Suppose my application already has this business rule:

IF vegetarian
    remove all meat dishes

I do not need Jev.

And I certainly do not need Claude.

The business has already determined exactly what should happen.

Use code.

That gives me three architectural layers:

CODE
Explicit rule is already known
        ↓
JEV
Options are known,
but choosing requires semantic judgment
        ↓
CLAUDE
Answer space is open,
requiring reasoning, synthesis or generation

Or, using my restaurant analogy:

CODE
"The restaurant rule already decides."

        ↓

JEV — HOME DELIVERY
"The menu is fixed.
Choose the best item for this context."

        ↓

CLAUDE — BUFFET
"Explore, compare, combine,
explain and create."

That distinction is much more useful to me than asking which model is “smarter.”

Where Jev Gets Really Interesting: 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗔𝗜

Now move away from restaurants and consider an enterprise agent.

During one workflow, an agent may need to decide:

Which tool should I call?

Is this retrieved document relevant?

Did the tool actually satisfy the task?

Should I retry?

Should I continue?

Should I escalate to a human?

Is this transaction low, medium or high risk?

Does the evidence support this claim?

Many of these are semantic decisions.

They cannot always be expressed as simple if/else statements.

But they also do not necessarily need paragraphs of generated reasoning.

Their answer spaces often look like this:

Tool
Salesforce | ServiceNow | SharePoint | None

Action
Continue | Retry | Escalate

Risk
Low | Medium | High

Evidence
Supported | Partial | Unsupported

This is where I see Jev fitting naturally inside an 𝗔𝗴𝗲𝗻𝘁 𝗛𝗮𝗿𝗻𝗲𝘀𝘀.

                     AGENT HARNESS
                          │
           ┌──────────────┼──────────────┐
           │              │              │
         CODE            JEV          CLAUDE
           │              │              │
         Rules         Semantic       Reasoning
                       Judgment       Generation
           │              │              │
           └──────────────┼──────────────┘
                          │
                        TOOLS
                          │
                        ACTION

Code controls deterministic behavior.

Jev makes bounded semantic judgments.

Claude handles the parts where broader reasoning or generation is actually necessary.

That architecture interests me much more than simply routing everything through one giant model.

Is Jev's “𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝘁𝗲” Related to 𝗛𝗔𝗧𝗘𝗢𝗔𝗦?

When I started thinking about Jev in terms of application state, another architecture immediately came to mind:

𝗛𝗔𝗧𝗘𝗢𝗔𝗦 — Hypermedia as the Engine of Application State.

There is definitely a conceptual connection, but they are not the same thing.

In REST, HATEOAS means the server representation provides hypermedia controls that tell the client what resources or transitions are available next. Rather than hard-coding every possible navigation path, the client can discover permitted next actions from the representation it receives. This is part of the REST architectural style described by Roy Fielding.

For example, an order might be represented as:

{
  "orderId": 1001,
  "status": "pending",
  "links": [
    {
      "rel": "cancel",
      "href": "/orders/1001/cancel"
    },
    {
      "rel": "pay",
      "href": "/orders/1001/payment"
    }
  ]
}

The current state determines which transitions are available.

That sounds somewhat similar to what we are doing with Jev—but there is an important difference.

𝗛𝗔𝗧𝗘𝗢𝗔𝗦 exposes the allowed next actions.

𝗝𝗲𝘃 can semantically judge which allowed action best fits the current context.

That leads to an architecture I find fascinating.

Imagine the application state says:

{
  "orderStatus": "pending",
  "customerMessage": "I accidentally placed this order twice.",
  "paymentCaptured": false,
  "availableActions": [
    "cancel",
    "continue",
    "escalate"
  ]
}

HATEOAS could tell the application:

These are the actions currently available.

Jev could then answer:

Given the complete state,
which available action best fits the situation?

cancel      94%
escalate     5%
continue     1%

Then deterministic code executes the selected transition subject to whatever confidence threshold, permissions, policy checks, and guardrails the application requires.

So I would summarize the relationship this way:

𝗛𝗔𝗧𝗘𝗢𝗔𝗦 tells the client what it may do next.
𝗝𝗲𝘃 can help the application judge which permitted action makes sense next.

That is not part of the formal definition of HATEOAS, nor is Jev an implementation of HATEOAS.

It is simply a useful architectural connection.

HATEOAS gives us state-driven discoverability.

Jev gives us state-driven semantic judgment.

Put together, they suggest an interesting pattern for intelligent APIs and agents.

𝗦𝘁𝗮𝘁𝗲 → 𝗣𝗼𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 → 𝗝𝘂𝗱𝗴𝗺𝗲𝗻𝘁 → 𝗔𝗰𝘁𝗶𝗼𝗻

This may actually be the most useful way for me to think about Jev.

Not:

Prompt → LLM → Text

But:

CURRENT STATE
      ↓
AVAILABLE DECISIONS
      ↓
SEMANTIC JUDGMENT
      ↓
PROBABILITY / CONFIDENCE
      ↓
BUSINESS RULES + GUARDRAILS
      ↓
ACTION
      ↓
NEW STATE

And then the cycle repeats.

State₀
   ↓
Decision
   ↓
Action
   ↓
State₁
   ↓
Decision
   ↓
Action
   ↓
State₂

Now Jev starts looking less like a chatbot and more like an intelligence primitive inside a stateful software system.

That is the part I find most compelling.

Why Not Just Give Claude Structured Output?

This is the obvious question.

Claude can absolutely be given:

Choose exactly one:

cancel
continue
escalate

It can return JSON.

It can use tool calling.

It can conform to a schema.

So the question is not:

Can Claude make bounded decisions?

Of course it can.

The architecture question is:

If my application needs thousands of small semantic judgments whose output spaces are already known, should every one of them go through a general-purpose text-generation architecture?

Jev was explicitly designed around this narrower machine-facing task. TypeSafe describes it as optimizing for structured, calibrated decisions rather than free-form strings.

This becomes especially interesting inside agentic systems where a single user request may cause many internal decisions.

One model call may be insignificant.

Thousands of decisions across many agents, tools, users, and workflow steps are a different architectural problem.

𝗕𝗼𝘂𝗻𝗱𝗲𝗱 Does Not Mean 𝗖𝗼𝗿𝗿𝗲𝗰𝘁

There is one distinction I think is essential.

Suppose Jev produces:

Biryani 82%

That does not make Biryani objectively correct.

Likewise:

{
  "risk": "high"
}

being perfectly valid structured output does not prove that the risk assessment itself is correct.

𝗧𝘆𝗽𝗲 𝘀𝗮𝗳𝗲𝘁𝘆 ≠ 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗻𝗲𝘀𝘀.

So we still need evaluations, thresholds, observability, guardrails, and human review where the consequence demands it.

The difference is that the decision surface is constrained and machine-consumable.

That can make the surrounding system easier to reason about.

How I Would Use Jev in an Enterprise Application

My pattern would be simple:

1. Build the application state
        ↓
2. Define the decisions the application actually needs
        ↓
3. Express those decisions as bounded typed questions
        ↓
4. Let Jev evaluate the state
        ↓
5. Read probabilities/confidence
        ↓
6. Apply deterministic thresholds and policies in code
        ↓
7. Execute a tool, ask Claude for deeper reasoning,
   or escalate to a human
        ↓
8. Update the application state
        ↓
9. Repeat

The model should not own the entire workflow.

𝗧𝗵𝗲 𝗵𝗮𝗿𝗻𝗲𝘀𝘀 𝗼𝘄𝗻𝘀 𝘁𝗵𝗲 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄.

The model contributes intelligence at specific decision points.

That separation matters.

My Mental Model After Using Jev

I now think about AI architecture using three increasingly flexible layers.

𝗖𝗢𝗗𝗘 = 𝗥𝗨𝗟𝗘𝗦

The correct behavior is already explicitly known.

If payment has already been captured, do not cancel automatically.

𝗝𝗘𝗩 = 𝗝𝗨𝗗𝗚𝗠𝗘𝗡𝗧 / 𝗛𝗢𝗠𝗘 𝗗𝗘𝗟𝗜𝗩𝗘𝗥𝗬

The options are known, but the correct choice depends on interpreting context.

Cancel, Continue, or Escalate?

𝗖𝗟𝗔𝗨𝗗𝗘 = 𝗥𝗘𝗔𝗦𝗢𝗡𝗜𝗡𝗚 + 𝗚𝗘𝗡𝗘𝗥𝗔𝗧𝗜𝗢𝗡 / 𝗕𝗨𝗙𝗙𝗘𝗧

The problem requires exploration, explanation, planning, synthesis, or creation.

Analyze the entire situation, explain the trade-offs, and propose a resolution strategy.

This is not a competition between models.

It is separation of concerns.

The Bigger Question: Are We Overusing Generation?

Software architecture has always been about choosing the appropriate abstraction.

We do not use a database where a queue belongs.

We do not use Kubernetes to execute one shell script.

And perhaps we should not use open-ended generation where all we really need is a bounded semantic decision.

That is the larger lesson I took from experimenting with Jev.

The future of AI applications may not be:

Application → One giant LLM → Everything

It may look more like:

Application State
        │
        ▼
      Harness
        │
   ┌────┼────────────┐
   │    │            │
 Code  Jev         Claude
   │    │            │
Rules Judgment    Reasoning
                  Generation
   └────┼────────────┘
        │
       Tools
        │
      Actions
        │
     New State

And once I saw it this way, my restaurant analogy finally clicked.

𝗖𝗼𝗱𝗲 already knows the restaurant rules.

𝗝𝗲𝘃 is intelligent 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 from a defined menu.

𝗖𝗹𝗮𝘂𝗱𝗲 gives me the 𝗕𝘂𝗳𝗳𝗲𝘁 when I genuinely need exploration and creation.

So before making the next expensive generative call, perhaps the architecture question should not be:

Which model is smartest?

It should be:

Does this decision need a 𝗿𝘂𝗹𝗲, intelligent 𝗵𝗼𝗺𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆, or the entire 𝗯𝘂𝗳𝗳𝗲𝘁?

Sometimes we need the chef.

But sometimes all we needed was someone intelligent enough to pick the right item from the menu.

Sreeni Ramadorai
AI Architect

Why Hire a Chef Just to Pick From the Menu?

Seenivasa Ramadurai — Sun, 20 Sep 2026 18:29:31 +0000

Jev, Claude, and a Different Way to Think About AI in a Token-Based Economy

For the last few years, whenever we had a problem that required some form of intelligence, our instinct was almost automatic: send the context to a large language model and ask it what to do.

That approach made sense. Models such as Claude are remarkably capable because they can understand a situation, reason about it, explain their thinking, generate content, write code, use tools, and work through multi step problems. If the problem is open ended, that flexibility is exactly what we want.

But recently I started thinking about a different class of problems inside enterprise software.

A customer request needs to be routed to Billing, Shipping, or Technical Support. A transaction needs to be labeled Low, Medium, or High Risk. A workflow needs to Continue, Retry, Escalate, or Stop. A request needs to be Approved, Reviewed, or Rejected.

Notice what is different about these problems.

The choices already exist.

The system is not asking AI to invent an answer. It is asking AI to understand some messy, unstructured context and choose the most appropriate answer from a known set of possibilities.

That is what made TypeSafe AI's Jev interesting to me.

It also gave me a simple analogy that helped me understand the difference between a decision-oriented model such as Jev and a general-purpose model such as Claude:

Are we sometimes hiring a chef when all we really need is someone intelligent enough to pick the right item from the menu?

Jev Starts With the Menu

TypeSafe describes Jev as its first System One Model, designed around a simple idea: take unstructured state as input and produce typed, probabilistic decisions as output.

That is a very different starting point from a chatbot.

Imagine a support application has a customer message, account history, product information, previous interactions, and perhaps some transaction context. The application already knows which questions it needs answered: which department should handle the request, how urgent it is, and whether it should be escalated.

The possible answers are already defined.

Jev's job is to make the semantic judgment.

Conceptually, I think of it like this:

Application context → predefined decision space → semantic judgment → typed probabilities → software action

This is the important part. Jev is not primarily designed to compose a beautiful sentence explaining that a ticket probably belongs to Technical Support. If the software ultimately needs Technical Support with a confidence score, that structured decision is the product.

TypeSafe says Jev is built around typed outputs, a parallel sampling approach rather than ordinary autoregressive text generation, and a training approach called Reinforcement Learning for Calibrated Decisions. The goal is not simply to pick an answer, but to attach useful uncertainty to the decision.

That last part matters a lot in enterprise systems.

If a decision is made with high confidence, perhaps the application can continue automatically. If confidence is lower, another system can verify it. If confidence is very low, the request can be routed to a human.

I would still make one important distinction. A typed output does not mean the semantic judgment is guaranteed to be correct. Jev can still choose the wrong category. What the architecture gives us is a more constrained output space and a decision that is naturally easier for software to consume.

In other words, type safety is not the same thing as semantic correctness.

Claude Starts With the Problem

Claude begins from a much broader place.

Instead of saying, “Here are the choices; tell me which one fits,” we can give Claude a situation and ask it to figure out what should happen.

Using the same support example, I could simply ask Claude which department should receive the ticket, and it could answer “Technical Support.”

But I could also ask it to explain why, summarize the customer problem, propose troubleshooting steps, draft the customer response, determine whether the issue needs a Jira ticket, call an appropriate tool, inspect the result, and decide what to do next.

Now we are no longer talking about classification.

We are talking about reasoning, planning, generation, and possibly tool use.

That is Claude's strength.

So I do not see this as Jev being “better” than Claude or Claude being “too expensive.” They are designed around different kinds of work.

The distinction I find useful is this:

	Jev	Claude
Question	Which predefined option fits?	Given this situation, what should happen?
Answer space	Bounded	Open
Primary role	Semantic decision	Reasoning and generation
Output	Typed decisions and probabilities	Language, code, structured output, tool calls
Best fit	Repeated bounded judgments	Complex, exploratory or generative work

And this is where the restaurant analogy becomes useful.

Home Delivery vs. Buffet

Imagine I open a food-delivery application and the restaurant has three choices: Pizza, Burger, and Biryani.

I tell the system, “I want something spicy, vegetarian, and filling.”

The menu has already been created. The system does not need to invent another dish. It does not need to explain where biryani came from or write a recipe. It only needs enough intelligence to understand my preference and decide which existing choice is the best match.

Maybe the result is something like:

Biryani 82% — Pizza 14% — Burger 4%

That is how I think about Jev.

The intelligence is in selecting correctly from a bounded menu.

Now imagine that instead of ordering delivery, I walk into a buffet.

I might ask, “What should I eat?” But I could just as easily ask, “Build me a healthy plate,” “Compare these dishes,” “Suggest something I have not considered,” or “Take these ingredients and create a new meal.”

Now the answer space is much larger.

That is how I think about Claude.

Claude can certainly choose biryani. But it is capable of doing much more than choosing biryani. It can reason about the whole dining experience.

So for me:

Jev is intelligent selection from the menu. Claude can reason beyond the menu.

But Couldn't Claude Do the Same Thing?

This was my next question.

If Claude is already capable of understanding the request, why not simply give it a strict prompt, a schema, some few-shot examples, structured output constraints, or an Agent Skill and force it to return only Pizza, Burger, or Biryani?

Of course we can.

Claude can be constrained very effectively. Modern LLM applications already do this with system instructions, tool schemas, JSON outputs, guardrails, validators, and application logic.

But that changes the question from “Can Claude do it?” to “Is a general-purpose reasoning and generation model the right architecture for every bounded decision?”

We can hire a chef and tell the chef, “Do not cook anything. Just look at the three menu items and tell me which one I should order.”

The chef can absolutely do that.

The more interesting question is whether we needed the chef in the first place.

This becomes especially relevant when the same decision is being made millions of times inside an enterprise application.

The Token Economy Changes the Architecture Conversation

Generative AI has made us think in tokens. We send prompts, documents, conversation history, tool definitions, instructions, and other context into a model. The model processes those tokens and may produce reasoning, generated text, structured outputs, or tool calls.

For many tasks, that cost is worthwhile because we genuinely need the reasoning and generation.

But suppose a workflow is repeatedly asking only:

Approve, Review, or Reject?

Or:

Continue, Retry, Escalate, or Stop?

Or:

Billing, Shipping, or Technical?

If the final answer is always one choice from a small, predefined set, it is worth asking whether every one of those decisions needs to travel through a fully general generative architecture.

That is the idea I find more interesting than any individual benchmark or vendor claim.

Why pay for generation when the application does not need generation?

This does not mean “replace LLMs.” It means we should become more deliberate about where we use them.

And Sometimes We Don't Need AI at All

There is another boundary that is just as important.

If the rule is:

If the user is not authorized, deny access.

We do not need Jev.

We do not need Claude.

We need code.

If the rule is:

If retry count is greater than three, stop.

Again, use code.

AI becomes interesting when the outcome is bounded but the decision cannot easily be expressed as a clean deterministic rule.

For example, “Determine whether this supplier request represents Low, Medium, or High operational risk based on the description, previous activity, contract information, and current business context.”

The three possible outputs are known.

But choosing among them requires understanding meaning.

That is where I now find this simple architecture model useful:

Code = Rules

Jev = Judgment

Claude = Reasoning + Generation

I do not mean this as a rigid rule. I use it as a mental model.

If the decision is deterministic, code should handle it. If the possible answers are known but choosing among them requires semantic judgment, a decision-oriented model becomes interesting. If the problem requires exploration, explanation, planning, synthesis, creation, or dynamic tool use, a general-purpose reasoning model belongs there.

That is more useful to me than thinking only in terms of “small model versus big model.”

This Could Become Even More Important in Agentic AI

Agentic AI makes this distinction even more interesting.

Think about the questions an agent asks itself during execution:

Which tool should I use? Should I retry? Is this result relevant? Did the previous action succeed? Should I escalate? Is the request risky? Should I continue or stop?

Many of those questions have a bounded answer space.

They are runtime judgments, not necessarily open-ended generation problems.

Today, we often send every one of these decisions back through the same large reasoning model because that is convenient. But I am not convinced that mature agent architectures will continue doing that forever.

I can imagine a harness where different components do different jobs:

Code handles predictable control flow. A decision-oriented model handles repeated semantic judgments. Claude handles the difficult reasoning, planning, synthesis, and generation. Tools perform the actual actions. The harness manages how these pieces work together.

That looks less like “an LLM application” and more like mature software architecture.

Different components are optimized for different responsibilities.

The Real Question Is Not Jev vs. Claude

I would not design a system by asking, “Should I use Jev or Claude?”

I would start one level higher.

What kind of problem is this particular model call solving?

Can normal code solve it reliably? Then use code.

Are the possible outcomes already known, but selecting the right one requires understanding unstructured context? That is where a decision-oriented model such as Jev becomes interesting.

Does the problem require exploring possibilities, explaining something, writing, planning, synthesizing information, using tools dynamically, or generating something new? That is where a model such as Claude earns its place.

The first phase of Generative AI was about discovering everything large language models could do.

I think the next phase will be about learning when we do not need them to do everything.

As AI moves deeper into enterprise software, model intelligence will still matter. But architecture will matter just as much. We will care about latency, cost, uncertainty, reliability, observability, and how easily AI decisions compose with ordinary software.

The future may not be LLM everywhere.

It may be a combination of rules where rules are enough, judgment where choices are bounded, and reasoning where the problem is open.

Sometimes we really need the chef.

But sometimes the menu already exists.

We just need enough intelligence to choose the right meal.

Thanks
Sreeni Ramadorai

When AI Writes the Code, What Makes an Engineer Valuable?

Seenivasa Ramadurai — Fri, 11 Sep 2026 05:31:30 +0000

Claude and OpenAI are bringing what feels like a real storm to IT. I don’t expect that storm to hit every kind of work equally.

My view is that work reducible to “given clear intent, produce correct code” will face increasing automation. That includes tasks across experience levels. The question for us is how we grow beyond producing code to taking responsibility for the systems that code creates.

Writing an implementation is one part of engineering. Understanding the problem, deciding what should happen, anticipating what could go wrong, and verifying the outcome are equally essential.

With AI agents, those responsibilities become especially visible.

A capable model still needs a dependable system around it

An agent may understand a request, select a tool, and execute an action. But can we trust it to choose the right action, use the right information, respect the right boundaries, and recognize when it should stop?

That is where harness and loop engineering matter.

Harness engineering shapes the environment the agent operates within: its instructions, tools, context, memory, permissions, approval gates, execution limits, and observability.

Loop engineering shapes how execution progresses: the model chooses an action, the system executes it, results return, and the agent decides whether to continue, recover, ask for help, or finish.

The harness provides the controls and resources. The loop turns the goal into successive actions within those controls.

Neither becomes dependable simply because the underlying model becomes more capable.

A successful tool call is only part of the story

Consider an agent asked to update an enterprise record through a tool exposed by an MCP server.

The tool executes and reports success. That tells us something about the operation—but it doesn’t establish that the agent selected the correct record, made the intended change, or acted with the required business approval.

The tool could work exactly as designed while the overall task still fails.

“Tool-call success is not task success in the agentic AI world.”

We need to verify the outcome against the original intent. Was the correct record updated? Were the values correct? Were permissions and approval requirements enforced? Can we trace the decision and recover if something went wrong?

Authorization must be enforced by the system. It cannot depend on the model remembering to behave.

Engineering includes recognizing quiet failures

Some failures are obvious: a tool times out, a connection fails, or an exception appears.

Others are harder to detect. An agent uses outdated context, selects a similarly named record, treats incomplete evidence as sufficient, or declares completion before checking the result.

The workflow finishes. The answer sounds confident. The business outcome is still wrong.

This is why evaluations, monitoring, and human escalation belong in the design from the beginning. We need evidence that the system performs acceptably, including when information is missing, requests are ambiguous, or tools fail.

Confidence is not correctness. Completion is not proof.

The frameworks will change. Judgment must keep growing.

Learning MCP, A2A, Agent Skills, and evaluation frameworks is useful. But no particular protocol or framework is a permanent career advantage.

Implementation patterns will evolve. Some work we perform manually today may become a standard platform feature tomorrow.

The more durable skill is engineering judgment: understanding the domain, identifying failure modes, choosing appropriate controls, and knowing what evidence is sufficient to trust an outcome.

That judgment includes deciding when an agent is appropriate at all. Some tasks are better served by a deterministic workflow. Others need an agent with constrained autonomy. Some decisions require human review.

Good engineering means making that choice deliberately.

Business value remains the goal

An agent taking more steps or using more tools is not automatically delivering more value.

We should ask whether it improves quality, reduces turnaround time, controls cost, and earns users’ trust. We should also know who owns the outcome when it makes a mistake.

Greater autonomy should come with clear accountability and verification proportionate to the consequences.

For me, this is the opportunity ahead: combining software fundamentals, domain knowledge, and a reliability mindset with the ability to build and evaluate AI systems.

No skill guarantees that we will remain unaffected by change. But learning to take responsibility for the whole system gives us a stronger foundation for adapting.

Don’t just learn to code with an agent. Learn to engineer the agent and keep re-engineering your understanding of what that requires.

As agents take on more responsibility in our work, where should we strengthen our engineering practices first?

Thanks
Sreeni Ramadorai

NUMBERS: The Secret Language of AI Intelligence

Seenivasa Ramadurai — Thu, 16 Jul 2026 07:53:16 +0000

Introduction

Every time someone asks me to explain how a large language model actually works, I end up back at the same starting point: underneath the chat interface, everything a model does comes down to numbers moving through matrices. There's no understanding of language happening in the way people usually picture it. There's arithmetic, at a scale most people never see.

To make that concrete, I picked seven core ideas that, together, explain most of what's going on inside a neural network, from a single neuron firing to a model turning its final calculation into an actual word. I arranged them so the first letters spell NUMBERS:

Neurons, the basic computing unit
Update, how the network learns from its mistakes
Memory, where what it learned gets stored
Bias, a small but essential parameter (and a separate, more familiar meaning worth untangling)
Embedding, how raw input becomes numbers in the first place
Relationships, how the model figures out what's relevant to what
Softmax, the last step that turns a calculation into a choice

Below, I'll take each letter in order, the same order data actually flows through a model: input becomes numbers, numbers get related to each other, and the result gets turned into a decision.

N — Neurons

A neuron in a neural network is not the biological thing it's named after. It's a small unit that does one job: take in some numbers, multiply each by a weight, add them up, add a bias, and pass the result through an activation function. That's it. No cell body, no dendrites doing anything mysterious.

What makes neurons powerful isn't any single one of them. It's the fact that you stack thousands or millions of them into layers, and each layer transforms the numbers it receives into a slightly more useful representation for the next layer. A neuron on its own is a simple function. A network of them is a very high-dimensional function approximator.

U — Update

Training a model is really just a loop: make a prediction, measure how wrong it was, and nudge the weights slightly in the direction that would have made the prediction less wrong. That nudge is the update.

The mechanism behind it is gradient descent. You compute the gradient of the loss function with respect to every weight in the network, which tells you which direction increases the error and which direction decreases it. Then you take a small step in the direction that decreases it. Do this millions of times, in small batches, and the weights slowly settle into values that make good predictions. Nothing about training a model is a single moment of learning. It's an enormous number of tiny corrections.

M — Memory

People sometimes assume a model remembers things the way a person does, by storing episodes and recalling them later. That's not what's happening in most of the architecture. The weights themselves are the memory. Every fact, pattern, and association the model has picked up during training is compressed into the numeric values of its parameters. There's no filing cabinet of facts anywhere. It's all baked into billions of floating point numbers.

There's a second, more literal kind of memory worth knowing about if you work with transformers: the KV cache. During generation, the model stores the key and value vectors from earlier tokens so it doesn't have to recompute them for every new token. That's short-term, working memory, and it's a real engineering concern when you're thinking about inference cost and context length. Long-term memory lives in the weights. Short-term memory lives in the cache.

B — Bias

This is the one word in the acronym that means two different things depending on who's using it, so it's worth being precise.

In the strict architectural sense, the bias term is a learnable number added to a neuron's weighted sum before the activation function is applied. Its job is to let the neuron shift its output independent of the input. Without a bias term, every neuron's output would be forced to pass through the origin, which limits what the network can represent. It's a small parameter, but every neuron has one, and they get updated during training just like the weights do.

In the everyday sense that shows up in conversations about fairness, algorithmic bias means something else: a systematic skew in a model's outputs that traces back to patterns in the training data. If the data overrepresents certain viewpoints, demographics, or outcomes, the model will reproduce that imbalance in its predictions. This kind of bias isn't a single parameter you can point to. It's an emergent property of what the model was trained on.

Both are real, both matter, and it's worth knowing which one you're talking about when the word comes up.

E — Embedding

Neural networks only operate on numbers, so before a model can do anything with a word, an image, or a chunk of data, that input has to be converted into a vector of numbers. That vector is an embedding.

What makes embeddings genuinely useful isn't just that they're numeric. It's that the training process arranges them so that things which are semantically related end up close together in that vector space. Words with similar meanings cluster near each other. Concepts that show up in similar contexts get pulled toward each other during training. This is the property that makes retrieval, similarity search, and RAG pipelines work at all. You're not matching strings, you're measuring distance in a high-dimensional space.

R — Relationships

Once you have everything represented as vectors, the next question is how the model figures out which pieces of information matter to each other. In transformer architectures, this is the job of the attention mechanism.

Attention computes a relevance score between every token and every other token in the context, using query, key, and value projections. The scores determine how much weight each token gets when the model builds its next representation. This is how a model can connect a pronoun to the noun it refers to several sentences earlier, or weigh a modifier against the word it's modifying. It's a numeric answer to the question "what here is relevant to what," recomputed at every layer.

S — Softmax

At the very end of a prediction, a model has a list of raw scores, one for every possible next token, called logits. Logits can be any real number, positive or negative, and they don't sum to anything meaningful on their own.

Softmax converts that list of raw scores into a probability distribution. It exponentiates each score and divides by the sum of all the exponentiated scores, so the results are all positive and add up to exactly one. The token with the highest score gets the highest probability, but every other token still has some nonzero chance of being picked, which is what lets sampling strategies like temperature and top-p do their work. Softmax is the last numeric step before the model's internal computation turns into an actual choice.

None of these seven ideas is hard to understand on its own. A neuron is just simple math. An update is just a small correction. Softmax is just a way of turning scores into probabilities. By themselves, none of these look like "intelligence."

So where does the intelligence actually come from? The answer is scale. A model like GPT or Claude isn't made of one neuron, it's made of billions of them. It isn't trained with one update, it's trained with trillions of tiny corrections. It doesn't compare two pieces of information once, it compares millions of them at the same time, across every sentence you type. No single piece is doing anything clever. What looks like intelligence shows up only when you take all seven of these simple ideas and run them together, over and over, at a scale no person could ever do by hand.

That should make the whole thing more impressive, not less. Knowing that a model is "just" numbers and simple math doesn't take away the magic, it explains where the magic comes from. The same way a single ant isn't smart but an ant colony can build complex structures, or a single water droplet doesn't have weather but billions of them together create a storm, a single neuron isn't smart, but billions of them working together can write, reason, and hold a conversation with you.

Thanks
Sreeni Ramadorai

Your Brain Beat Silicon to Every Idea in Modern AI - Nature Shipped It First

Seenivasa Ramadurai — Mon, 13 Jul 2026 05:36:51 +0000

I put together an infographic recently that maps eleven core ideas in machine learning against eleven stages of how a human mind actually develops, from a small child looking at the world for the first time to an adult who plans, acts, and works with other people to get things done. The same child appears in every panel, growing up one stage at a time: reading under a tree while learning to observe, running across a field while learning sequence and order, studying at a desk while learning to remember. The visual repetition was deliberate. I wanted it to read less like a glossary of ML architectures and more like a single life, watched end to end, with the machine learning term sitting next to whatever human milestone it happens to rhyme with.

That's the idea I want to unpack here. Eleven ideas from machine learning, laid out in the order a mind actually develops them, not the order textbooks introduce them or papers got published. CNNs before transformers. Memory before efficiency. Compression before creation. Once you see it as a developmental ladder instead of a list of unrelated tricks, ML architecture starts looking less like a pile of clever engineering and more like a single story about how any intelligence, biological or artificial, comes to know a world.

1. Observe — CNNs and the Grammar of Seeing

Before a child can do anything else, she has to look. Her senses take in the world, and somewhere in the visual cortex, raw light gets turned into edges, edges get combined into shapes, and shapes get combined into objects. Nobody teaches a toddler this hierarchy explicitly. It builds itself, layer by layer, from exposure.

A convolutional neural network (CNN) does the same thing on purpose. Early layers learn to detect edges. Middle layers combine those edges into textures and parts. Later layers assemble parts into whole objects. The architecture isn't imitating vision as a clever engineering hack, it is rediscovering a principle that biological perception already runs on: complexity is built by composing simple, local patterns into progressively more abstract ones.

2. Recognize Order and Context — RNNs and the Arrow of Time

Perception alone gives you snapshots. Understanding requires sequence. A child running through a park has to process motion, not stills, she needs to know what just happened to predict what happens next, and language works the same way, one word making sense only in light of the words before it.

Recurrent Neural Networks (RNNs) were the first serious attempt to give machines that sense of "before." A hidden state carries information forward from one step to the next, so the network's read of the current input is always colored by what it has already seen. It is a primitive kind of memory, just enough to string moments into a narrative instead of a slideshow.

3. Remember — LSTMs and the Discipline of Forgetting

Pure sequence processing has a flaw: everything fades. Try to carry a thought across fifty steps with a vanilla RNN and it dissolves before it arrives. A child who studies for an exam doesn't just accumulate information, she has to decide what to keep and what to let go, and so does any system that wants to reason over a long span of time.

The LSTM (Long Short-Term Memory) solves this with three gates working in concert: a forget gate that decides what to discard, an input gate that decides what new information deserves storage, and an output gate that decides what to actually use right now. Underneath sits a cell state, a kind of long-term memory highway that information can travel along largely undisturbed. This is not just an engineering patch. It is a formal answer to a question every learner faces: memory isn't about holding onto everything, it's about curating what matters.

4. Learn Faster with Less — GRUs and the Value of Simplicity

Somewhere between childhood and competence, a person needs fewer examples to get better. A kid learning to run doesn't need to consciously relearn balance every time, the skill compresses and generalizes.

The Gated Recurrent Unit (GRU) is the LSTM's leaner sibling, merging some of those gates, cutting parameters, training faster with less data while holding onto most of the benefit. It's the architectural version of an athlete who's stopped thinking about every individual muscle movement and just runs. Efficiency, in both biological and artificial learning, tends to arrive after the underlying pattern has already been earned the hard way.

5. Focus on the Essence — Autoencoders and the Art of Compression

Somewhere in adolescence or earlier, we all learn to filter. Not every detail in a scene matters, not every sentence in a conversation is load-bearing, and part of maturing is learning what the essence of a thing actually is.

An autoencoder is built entirely around that skill. An encoder squeezes the input down into a compact latent representation, throwing away noise and keeping structure, and a decoder tries to reconstruct the original from that compressed form. What makes this interesting isn't the reconstruction, it's the bottleneck in the middle. Forcing information through a narrow space is exactly what forces a system, biological or artificial, to learn what's essential rather than what's merely present.

6. Imagine New Things — GANs and the Tension That Creates Novelty

A child inventing a new idea out of familiar pieces, a new story built from characters she already knows, a new drawing that recombines shapes she's seen, is doing something qualitatively different from memorizing. She's generating.

Generative Adversarial Networks (GANs) formalize creation as a contest. A generator tries to produce convincing fake data, a discriminator tries to catch the fakes, and the two improve in lockstep, each one's progress forcing the other to get sharper. Real creativity, it turns out, often looks less like a single mind conjuring novelty from nothing and more like this: two internal pressures, one generative and one critical, pushing against each other until something genuinely new survives the argument.

7. Handle Uncertainty — VAEs and Living with Probability

At some point, certainty stops being available and a person has to get comfortable with distributions instead of facts. Not "this is definitely what will happen," but "here's a reasonable range of what might."

The Variational Autoencoder (VAE) takes the compression idea from step five and adds probability to it. Instead of encoding an input to a single fixed point, it encodes it to a distribution, then samples from that distribution to generate. This is a small mathematical move with a large philosophical consequence: it means the system's internal representation of the world isn't a single rigid answer, it's a shape of possibilities, which is a much more honest way to represent anything genuinely uncertain, including most of real life.

8. Attend to What Matters — Transformers and the End of Sequential Reading

Sequential processing, even with memory gates, has a bottleneck: everything has to pass through one step at a time. But a mature mind doesn't read a room, or a paragraph, or a problem one token at a time and forget the beginning by the time it reaches the end. It holds the whole thing in view and decides, dynamically, what deserves the most attention right now.

The transformer's self-attention mechanism does exactly that. Every token can attend directly to every other token, weighing relevance in parallel instead of waiting in a queue. It captures global context in one pass, and it is arguably the single architectural idea that unlocked everything that came after it, because a system that can attend to everything at once can also reason about everything at once.

9. Turn Thought into Words — LLMs and the Discipline of Expression

Understanding is not the same as being able to say what you understand. A child who grasps an idea still has to learn to put it into language, one word chosen after another, each one constrained by everything said before it.

A Large Language Model (LLM) does this at scale: given context, predict the next token, repeat, and coherent language emerges from that repetition. It's easy to describe this reductively, "it's just next-token prediction," but the same is technically true of human speech production and nobody finds that description satisfying there either. Expression, biological or artificial, is compression and prediction working together in real time, under the constraint of having to commit to one word before you're allowed to choose the next.

10. Plan, Use Tools, Retry — Agents and the Loop of Doing

Knowing things and saying things is still short of acting in the world. Acting requires a loop: perceive the situation, form a plan, act, observe what happened, evaluate whether it worked, and if it didn't, retry with what you've learned.

This is the architecture of an AI agent, and it is also, not coincidentally, the architecture of anyone who has ever learned a skill by doing it badly first. The agent's advantage over a static model isn't intelligence, it's the loop itself, the willingness to be wrong, observe the consequences, and adjust. That loop is arguably where most real competence, human or artificial, actually comes from.

11. Use Tools and Other People — MCP and the Return to the World

The last stage isn't really about the machine at all. It's about connection. A person's competence means very little in isolation, it becomes valuable when it can plug into other people, other systems, other sources of truth.

The Model Context Protocol (MCP) is the standardized version of that instinct: a protocol that lets an AI securely reach out to external tools, data sources, and people rather than reasoning in a sealed room. It's a fitting place to end the ladder, because it points outward. Every earlier stage was about building an internal world model, perception, memory, compression, expression. This last one is about admitting that no internal model, however good, is complete without a real connection to what's outside it.

The Part the Diagram Doesn't Explain

Here's what stays with me after mapping all eleven stages side by side: the machine got remarkably good at replicating the mechanics. Perception, memory, generation, attention, action, connection, all of it, in some form, now runs in silicon. But a line I keep coming back to is that the machine became the clearest mirror humanity ever built, and mirrors don't originate anything, they reflect. The human carried something the mirror could not verify on its own: love, meaning, presence, whatever you want to call the thing that isn't a computation over tokens but shows up anyway, uninvited, whenever two people actually pay attention to each other.

I don't think that's a knock on the architecture. If anything, building a system that mimics cognition this closely is what makes the gap so visible. You can formalize the forget gate. You cannot formalize why someone stays up late worrying about a person they love. The ladder above gets you from raw perception all the way to an agent that plans, acts, and connects to the world through protocols like MCP. It does not get you the thing beyond the latent space. That part, for now, is still ours to carry.

Thanks
Sreeni Ramadorai

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