DEV Community: Robin Singh

Why Smarter AI Doesn't Mean Smarter Robots (Yet)

Robin Singh — Tue, 13 Oct 2026 22:40:01 +0000

Robots and AI are often talked about as if they are the same project, but they are not. The AI research that gets headlines (big vision models, reinforcement learning, large language models) mostly runs in simulation or in a data center. The robot has to deal with gravity, friction, battery drain and the fact that a dropped object does not generate a loss function. This post looks at where the two fields actually meet today, what each AI technique contributes to a physical machine, and where the real bottlenecks are.

Where AI Actually Touches a Robot

A robot's software stack usually has three layers: perception, planning, and control. AI has made real progress in the first two. Control, the part that turns a plan into motor commands, is still mostly classical: PID loops, model predictive control, inverse kinematics. The AI work sits on top of that layer, not inside it.

That split explains why a robot can have a strong vision model and still fail to pick up a cup. The model tells it where the cup is. It does not tell the motors how much force to apply before the cup slips.

Vision Models: Seeing Before Moving

Vision is the most mature AI contribution to robotics. Object detection and segmentation models let a robot find items on a shelf, identify a surgical landmark, or track a package on a conveyor. Depth estimation, often from stereo cameras or LIDAR fused with a learned model, gives the robot a 3D sense of its surroundings instead of a flat image.

# simplified perception loop
frame = camera.capture()
detections = vision_model.predict(frame)
for obj in detections:
    depth = depth_estimator.estimate(obj.bbox, frame)
    world_pose = camera_to_world(obj.bbox, depth)
    planner.add_target(world_pose)

This loop runs several times a second on a real robot. The model's job ends at producing a pose. Everything after that, approaching the object and gripping it with the right force, is a separate problem.

Reinforcement Learning: Learning to Move

Reinforcement learning (RL) trains a lot of locomotion and manipulation policies. Instead of hand coding a walking gait, you simulate the robot thousands or millions of times, reward it for staying upright and moving forward, and let the policy emerge.

# simplified RL training loop
for episode in range(num_episodes):
    state = env.reset()
    done = False
    while not done:
        action = policy(state)
        next_state, reward, done = env.step(action)
        buffer.store(state, action, reward, next_state)
        state = next_state
    policy.update(buffer.sample())

Boston Dynamics' Atlas and Tesla's Optimus both lean on this kind of training for balance and recovery. Sim-to-real transfer is the hard part: a policy that works in simulation often needs real-world fine-tuning because friction, motor backlash and sensor noise never match the simulator exactly.

Humanoid and Mobile Robots in Production Today

Warehouse and logistics: Amazon's fleet of mobile robots moves shelves and packages across fulfillment centers, guided by AI path planning that reroutes around people and obstacles in real time.
Humanoids: Figure's robots and Tesla's Optimus are being tested on tasks like sorting and simple assembly, using vision-language-action models to map a camera feed and a spoken instruction to a sequence of movements.
Surgical robots: Intuitive Surgical's da Vinci system still relies on a human surgeon for decisions, but AI assists with instrument tracking and tissue recognition.
Autonomous drones: AI-driven drones now handle inspection of power lines, crop monitoring and search and rescue, using onboard vision models for obstacle avoidance where GPS is unreliable.

What Large Language Models Add

LLMs are showing up in robotics as planners, not controllers. Given a high-level instruction like "clear the table," an LLM can break it into subtasks (locate objects, pick each one up, place it in a bin) that get handed to lower-level motion policies. Google's RT-2 and similar vision-language-action models go further, mapping images and text directly to robot actions. The LLM does not move a single motor; it decides what should happen next and leaves the execution to the control stack described earlier.

The Real Limitations

Power: A humanoid robot like Optimus runs for roughly 2-5 hours on a charge doing moderate work, far short of a human shift.
Dexterity: Human hands have 27 degrees of freedom and a sense of touch that current robot grippers still cannot match, which is why most warehouse robots move boxes rather than individual items.
Cost: A capable manipulation arm with force sensing still costs tens of thousands of dollars, which keeps humanoid robots out of most workplaces for now.
Safety: A robot operating near people needs certified force limits and fail-safes, which slows down deployment far more than the AI model does.

Where This Is Headed

The next few years look less like "robots get smarter" and more like "robots get cheaper and more reliable at narrow tasks." Expect AI to keep improving perception and task planning while mechanical engineering, battery density and manufacturing cost close the gap on the physical side. The bottleneck has shifted: it used to be the software. Increasingly, it is the hardware underneath it.

Dev

Robin Singh — Sat, 10 Oct 2026 22:40:07 +0000

This is testing

test

Robin Singh — Sat, 03 Oct 2026 03:31:01 +0000

test

Meet Jev: The AI That Refuses to Chat With You (On Purpose)

Robin Singh — Thu, 24 Sep 2026 17:42:01 +0000

Every AI model you've heard of talks. This one was built to never say a word — and that's exactly why developers are excited about it.

Here's a question you've probably never had to ask before: what if an AI model just... didn't write anything? No essays, no explanations, no friendly chatbot replies. Just a fast, confident decision, and nothing else. That's Jev — a new model from a startup called TypeSafe AI, built by someone who helped create ChatGPT itself. And the whole point of it is that it does less than ChatGPT, on purpose, so it can do that one thing much faster and much more reliably.

What Jev actually does

Think about all the tiny decisions software makes behind the scenes every day: is this email spam or not, which support queue should this ticket go to, does this comment break the community rules, how likely is this customer to churn. Right now, a lot of companies handle these by calling a full AI chatbot — the same kind of model you'd use to write an essay — just to get back a one-word answer buried inside a paragraph.

Jev skips the paragraph. You give it some information and a set of possible answers, and it hands back one of those answers directly, plus a percentage telling you how confident it actually is. No essay, no chit-chat, no extra words to sift through. Just: here's the answer, and here's how sure I am.

How it's different from ChatGPT, Claude, or Gemini

The AI chatbots you already know are built to hold a conversation — they think through a response one word at a time, the way you might think through a sentence as you speak it. That's great for writing and explaining things, but it's slow and expensive when all you actually needed was a single yes-or-no answer.

Jev works completely differently: instead of writing word by word, it produces its whole answer at once, already locked into a fixed format you defined ahead of time — like a multiple-choice answer instead of an open essay question. Because it can only ever pick from the choices you gave it, it literally can't make something up or go off-script the way a chatbot sometimes does. And because it skips the whole "write it out one word at a time" process, it's reportedly dozens of times faster and a fraction of the cost for this kind of task.

The trade-off is real, though: Jev can't write you an email, a story, or a thoughtful explanation. It only knows how to choose, score, or rate — nothing more. It's not a smaller, weaker version of ChatGPT. It's a completely different tool built for a completely different job.

Why this could actually matter

Right now, a huge number of AI-powered products are quietly using an expensive, slow chatbot to make small, repeated decisions it was never really designed for — like using a sports car to deliver a single envelope down the street. If a purpose-built tool like Jev can genuinely do that specific job faster, cheaper, and more predictably, the likely shift isn't "Jev replaces ChatGPT." It's that apps start using both: a fast, no-nonsense decision-maker like Jev handling the constant background judgment calls, and a full conversational model like ChatGPT or Claude stepping in only when something actually needs to be written, explained, or reasoned through in depth.

For everyday users, that split would mostly be invisible — you'd just notice AI-powered apps getting snappier and cheaper to run, without any drop in quality. For developers and companies, it's a meaningfully different way to think about building with AI: not "which chatbot should I use everywhere," but "which decisions actually need a conversation, and which ones just need an answer."

My First Draft

Robin Singh — Thu, 24 Sep 2026 17:32:00 +0000

What is new

[The headline change, in one or two sentences.]

Improvements

[An improvement, and who it helps]
[Another improvement]

Fixes

[What was broken, and what happens now]

Upgrading

[Anything the reader has to do, or that nothing is needed.]

MCP Went Stateless. Your AI Agent Still Needs State.

Robin Singh — Thu, 24 Sep 2026 01:02:01 +0000

One of the more interesting changes in the AI engineering ecosystem in 2026 is happening below the model layer.

The latest MCP specification moved the protocol toward a stateless core.

That sounds like agents should become stateless too.

They shouldn’t.

In fact, as AI agents become longer-running, more autonomous, and capable of executing real actions, application-level state becomes even more important.

The distinction is simple:

MCP should not need to remember your connection.

Your agent absolutely needs to remember its work.

This difference becomes critical once you move from demos to production.

What Changed in MCP?

The 2026-07-28 Model Context Protocol specification introduced a stateless protocol core.

Instead of depending on persistent sessions between an MCP client and server, requests can carry enough information to be handled independently.

That means an MCP request can potentially hit:

Client

|

v

Load Balancer

|

+------> MCP Server 1

|

+------> MCP Server 2

|

+------> MCP Server 3

without requiring the load balancer to keep routing a particular client back to the same server instance.

The new specification removed the old session-oriented initialize flow and Mcp-Session-Id, making requests more self-describing and much easier to scale using conventional HTTP infrastructure.

This is a good architectural change.

But there is an important trap here.

Stateless transport does not mean stateless workflow.

An AI Agent Is Usually a State Machine

Imagine an agent responsible for refunding a customer.

The workflow might look like:

What happens during those 30 minutes?

If your agent state only exists inside:

agent = Agent(...)

result = agent.run(...)

you have a problem.

The process might restart.

A deployment might happen.

The request could reach another Kubernetes pod.

The machine could disappear.

The approval request could arrive hours later.

The workflow therefore cannot depend on process memory.

You need durable state.

The Wrong Architecture

A common first implementation looks something like this:

pending_runs = {}

async def execute_agent(user_id, request):

result = await agent.run(request)

if result.requires\_approval:  
    pending\_runs\[[result.id](http://result.id)\] = result  

    return {  
        "status": "waiting\_for\_approval",  
        "run\_id": [result.id](http://result.id)  
    }

Later:

async def approve(run_id):

run = pending_runs[run_id]

return await run.resume()

It works perfectly...

until you deploy it.

Consider two instances:

         Load Balancer  
          /         \\  
         /           \\  
    Server A       Server B

The agent runs on Server A.

pending_runs["run_123"]

exists only in Server A's memory.

The user clicks:

Approve

The load balancer sends the request to Server B.

Server B asks:

pending_runs["run_123"]

and gets:

KeyError

Your AI model isn't the problem.

Your prompt isn't the problem.

Your distributed system is.

The Better Architecture

Persist the workflow state.

             ┌───────────────┐  
             │     Client    │  
             └───────┬───────┘  
                     │  
                     ▼  
             ┌───────────────┐  
             │ Load Balancer │  
             └───────┬───────┘  
                     │  
         ┌───────────┴───────────┐  
         ▼                       ▼  
   ┌───────────┐           ┌───────────┐  
   │ Server A  │           │ Server B  │  
   └─────┬─────┘           └─────┬─────┘  
         │                       │  
         └───────────┬───────────┘  
                     ▼  
           ┌─────────────────┐  
           │ Workflow State  │  
           │                 │  
           │ Postgres        │  
           │ Redis           │  
           │ Temporal        │  
           │ Durable Runtime │  
           └─────────────────┘

Now the agent runtime becomes replaceable.

Any server can reconstruct the current workflow.

Separate Three Different Types of State

This is where production agent architecture becomes interesting.

I usually think about agent state as three different layers.

1. Conversation State

This is what the model needs to understand the interaction.

For example:

{

"messages": [],

"summary": "...",

"user_preferences": {},

"retrieved_context": []

}

This state controls what the model knows.

2. Workflow State

This is what your application needs to understand where execution currently is.

For example:

{

"workflow_id": "refund_39281",

"status": "WAITING_FOR_APPROVAL",

"current_step": "refund_confirmation",

"order_id": "ORD_8821",

"refund_amount": 149.99

}

This is not prompt context.

It is distributed-system state.

3. Side-Effect State

This tells you what the agent has already done.

For example:

{

"email_sent": true,

"refund_created": false,

"crm_updated": true

}

Without this state, retries become dangerous.

Imagine:

Agent calls refund API

↓

Network timeout

↓

Agent doesn't know whether refund succeeded

↓

Agent retries

↓

Customer gets refunded twice

That is why production agents need idempotency.

Idempotency Becomes Extremely Important

Every side-effecting tool should ideally support something similar to:

refund(

order_id="ORD_8821",

amount=149.99,

idempotency_key="workflow_928_step_7"

)

Then:

Attempt 1

workflow_928_step_7

↓

Refund $149.99

If the workflow retries:

Attempt 2

workflow_928_step_7

↓

Already processed

↓

Return existing result

instead of creating another refund.

This applies to much more than payments.

Think about:

send_email()

create_ticket()

delete_resource()

publish_post()

update_crm()

book_meeting()

deploy_service()

transfer_money()

Once AI agents can perform actions, retry semantics become part of AI safety.

Human Approval Is Also a Distributed Systems Problem

Human-in-the-loop workflows are becoming common for sensitive actions.

For example:

The important word here is:

resume

You don't want to restart the entire agent.

You want to continue from a durable checkpoint.

Modern agent frameworks increasingly expose this kind of pause/resume model. OpenAI's agent documentation, for example, describes storing serialized state when human review happens later and continuing the same run once the decision arrives.

This changes how we should think about agent execution.

An agent isn't necessarily:

HTTP request

↓

LLM

↓

response

It may instead be:

Start

↓

Think

↓

Tool

↓

Think

↓

Tool

↓

Pause

↓

--- 4 hours later ---

↓

Resume

↓

Tool

↓

Think

↓

Complete

That is much closer to a workflow engine than a normal API request.

Durable Execution Is Becoming Part of the Agent Stack

Long-running agents introduce familiar distributed-system problems:

process crashes

network failures

duplicate messages

timeouts

retries

partial execution

concurrent updates

human approvals

scheduled execution

deployment during execution

These problems existed long before LLMs.

We're just rediscovering them inside agent systems.

A production architecture may therefore look like:

                    User  
                     |  
                     v  
                API Gateway  
                     |  
                     v  
             Agent Orchestrator  
                     |  
         ┌───────────┼───────────┐  
         │           │           │  
         v           v           v  
       Model       Tools        MCP  
         │           │           │  
         └───────────┼───────────┘  
                     |  
                     v  
            Durable Workflow  
                     |  
        ┌────────────┼────────────┐  
        │            │            │  
        v            v            v  
     State DB      Queue       Event Log

Frameworks are increasingly acknowledging this requirement. LangChain, for example, describes durable execution, memory, human-in-the-loop support, multi-tenancy, and observability as infrastructure needed underneath long-running production agents.

MCP and Durable Execution Solve Different Problems

This distinction is worth remembering.

MCP answers:

How does an agent communicate with tools and external systems?

Durable execution answers:

How does an agent reliably continue working over time?

They complement each other.

You might have:

Agent

|

| MCP

v

Salesforce

Agent

|

| MCP

v

GitHub

Agent

|

| MCP

v

Slack

while the overall workflow is managed separately:

Step 1: Fetch GitHub issue

Step 2: Analyze code

Step 3: Generate patch

Step 4: Run tests

Step 5: Wait for approval

Step 6: Create PR

Step 7: Post Slack notification

The MCP servers do not need to remember the entire workflow.

The orchestrator does.

Observability Also Changes

Traditional API monitoring might tell you:

POST /agent

200 OK

Duration: 4.2s

That isn't enough.

A production agent might execute:

Run #8291

├── Model call

├── retrieve_documents

├── Model call

├── search_customer

├── Model call

├── update_customer

├── approval_required

├── PAUSED

├── approval_received

├── update_salesforce

├── send_email

└── complete

You need to understand the complete trajectory.

That means tracking:

model calls

tool calls

tool arguments

tool responses

latency

token usage

retries

approvals

guardrail decisions

state transitions

errors

cost

Agent platforms are moving in this direction as well. Current OpenAI tooling, for example, exposes structured tracing across model calls, tool calls, handoffs, guardrails, and custom spans.

The Production Pattern

If I were designing a serious agent system today, I would separate it roughly like this:

┌───────────────────────────────┐

│ API Layer │

└───────────────┬───────────────┘

│

▼

┌───────────────────────────────┐

│ Agent Orchestrator │

│ │

│ Planning │

│ Reasoning │

│ Tool selection │

└───────────────┬───────────────┘

│

┌────────┴────────┐

│ │

▼ ▼

┌─────────────┐ ┌───────────────┐

│ MCP / Tools │ │ Workflow │

│ │ │ Runtime │

│ Stateless │ │ │

│ interface │ │ Durable State │

└─────────────┘ └───────┬───────┘

│

┌───────┼───────┐

▼ ▼ ▼

DB Queue Logs

Notice the separation:

MCP → tool interoperability

LLM → reasoning

Workflow layer → durability

Database → state

Queue → asynchronous execution

Tracing → observability

Guardrails → control

Trying to make the LLM responsible for all of these concerns is where agent architecture usually starts falling apart.

The Bigger Lesson

The AI industry spent the first phase of the LLM boom asking:

Which model should we use?

Then:

Which prompt should we use?

Then:

Which agent framework should we use?

The more important production questions are increasingly becoming:

How does the workflow recover?

How do we resume execution?

How do we prevent duplicate side effects?

Where does state live?

How do we authorize tool calls?

How do we trace a 50-step execution?

How do we roll out a new agent version safely?

How do we replay failed workflows?

How do we evaluate complete trajectories?

These are not fundamentally AI questions.

They are distributed systems questions.

And that might be one of the most important shifts happening in AI engineering right now.

MCP becoming more stateless doesn't remove state from agent systems.

It simply puts state where it belongs.

In the application and workflow layer, not the transport protocol.

Final Thought

The next generation of AI applications probably won't look like:

User → Prompt → LLM → Response

They will look more like:

User

↓

Agent

↓

Planner

↓

Tools / MCP

↓

Durable Workflow

↓

Events

↓

Approvals

↓

Retries

↓

Observability

↓

Result

The model may be the brain.

But production reliability still comes from good systems engineering.

And no amount of prompt engineering can replace that.

This is my post

Robin Singh — Thu, 24 Sep 2026 00:51:01 +0000

Testing the post