TL;DR: We analyzed registration answers from 256 confirmed builders attending Claws Out: Hard Problems Night with GMI Cloud × WorkOS × AdaL. The signal was clear: agent builders are no longer blocked by ideas or demos. They are blocked by productionization — reliability, scaling, and review velocity.

At Claws Out: Hard Problems Night with GMI Cloud × WorkOS × AdaL in San Francisco, the room was full of agent builders talking about the messy middle: what breaks after the demo works.

The event had hard-problem sessions from builders, then breakout discussions on agent reliability, infrastructure/cost optimization, and enterprise readiness. The premise was simple:

“The interesting parts of the failures don't get written down.”

So we looked at the registration answers from confirmed attendees: what they were building, and the hardest production issue blocking them right now.

Claws Out: Hard Problems Night at WorkOS San Francisco

The result was not subtle: the top issues were exactly the ones production agent teams keep running into — reliability, scaling, and review velocity.

The data

The registration table had:

Metric	Count
Total guest rows	1,499
Approved / confirmed guests	256
Approved / confirmed rate	17.1%

For this analysis, we looked only at the 256 approved / confirmed guests.

Two free-response questions were especially useful:

What are you currently building or deploying in production?
What is the hardest production issue you are actively blocked on right now?

We categorized answers directionally. Some were detailed, like:

“Building LLM-powered observability systems and a secure semantic search backend…”

Others were short:

“latency”

“Auth”

“Code reviews”

So the categories are not perfect labels. They are signals from a room of builders.

What confirmed guests are building

The strongest signal: this was an agent-heavy audience.

Category	Count	% of confirmed guests
AI agents / agent platforms	43	16.8%
Developer tools / coding infrastructure	38	14.8%
Enterprise / GTM / sales / operations	12	4.7%
Data / observability / search / evals	10	3.9%
Education / health / consumer	10	3.9%
Content / media / social	8	3.1%
Robotics / cyber-physical / geospatial	7	2.7%
Fintech / payments / crypto	6	2.3%

What confirmed guests are building

Representative answers included:

“Agents for data engineers”
“Automation coding agent”
“Agent builder”
“Agent Control Plane”
“B2B SaaS AI agents with sprinkles of swarm orchestration”
“Building toward a mobile coding agent”
“LLM evals platform”
“Financial analyst agent set”
“Structured memory for agents”
“International payments with agents”

This matters because the room was not just “AI curious.” Many attendees were already thinking in systems: agents, control planes, evals, memory, observability, orchestration, and deployment.

The interesting part was not what they wanted to build.

It was what was slowing them down.

The top agent blockers

If we exclude vague or placeholder answers, the top production blockers were:

Rank	Blocker	Count	% of confirmed guests
1	Reliability / determinism / correctness	32	12.5%
2	Scaling / latency / throughput	24	9.4%
3	Review velocity / human process	20	7.8%
4	Security / auth / compliance	18	7.0%
5	Cost / tokens / model constraints	13	5.1%
6	Multi-agent orchestration / architecture	10	3.9%
7	Evals / metrics / ROI validation	8	3.1%

Hardest production blockers among confirmed guests

The pattern is important:

Agent builders are not blocked because they cannot make the model do something impressive once.

They are blocked because they need the system to do the right thing repeatedly, cheaply, quickly, securely, and with enough evidence that a human team will trust it.

That is production.

Blocker #1: reliability, determinism, and correctness

The biggest concrete blocker was reliability.

People wrote things like:

“Ensuring reliability and correctness in LLM-driven systems.”
“Reliability”
“Determinism”
“Reliability and consistency of work”
“Constantly finding bugs during testing and fixing the bugs”
“Tool calling”
“Reliably getting outputs from on-device models.”

This is the core shift in agent building.

A demo can tolerate variance. A production workflow cannot.

If an agent writes code, touches customer data, triggers an API, books a meeting, modifies infrastructure, or sends a message, then “usually works” is not enough. Teams need:

reproducible runs
clear traces
bounded tool access
robust fallback behavior
regression tests
evals that catch behavior drift
review checkpoints before high-risk actions

The hard part is that agent failures are rarely one-dimensional. A broken run might involve prompt ambiguity, model variance, missing context, bad retrieval, fragile tool output parsing, weak state management, or a human approval step that happened too late.

Reliability is not one feature. It is the architecture.

Blocker #2: scaling, latency, and throughput

The second major blocker was performance under load.

Representative answers:

“Scaling”
“throughput”
“latency”
“Stress testing our system at scale”
“Inferences”
“The web scraping speed is always being limited.”

Agents are expensive in a way normal apps are not.

A single user action can trigger:

multiple LLM calls
tool calls
browser actions
retrieval
code execution
file reads
reflection loops
eval checks
human review requests

That means latency and cost compound quickly.

For production agent systems, optimization is not just picking a cheaper model. It is deciding:

which tasks need frontier reasoning
which tasks can run on smaller models
what context should be cached
which work should be delegated to subagents
when to stop an agent loop
how to batch or parallelize tool calls
how to detect low-value retries
how to trace cost per outcome, not just cost per token

The builders in the room were not asking “Can agents work?”

They were asking:

Can this work at the speed, cost, and reliability my users expect?

Blocker #3: review velocity

The third blocker surprised some people, but it may be the most important one: review velocity.

Review velocity means how quickly a team can validate, approve, and ship changes without sacrificing quality.

The answers behind this category included:

“reviewing PRs more quickly”
“Human code review”
“Code reviews”
“Moving fast enough”
“development process”
“Agentic development with quality and speed”

This is the bottleneck created by successful automation.

If an agent can produce ten pull requests, three infrastructure changes, five test updates, and two docs edits in a day, the bottleneck is no longer generation.

The bottleneck becomes review.

A team needs to answer:

What did the agent change?
Why did it change it?
What files or systems are affected?
What tests were run?
What risk remains?
Does this require human approval?
Who owns the outcome if the agent wrote it?

Without better review workflows, teams get stuck between two bad options:

Slow everything down until humans can manually inspect every diff.
Rubber-stamp agent output and hope the tests caught enough.

Neither scales.

This is why review velocity belongs next to reliability and scaling. It is not a “process” issue separate from engineering. It is a production constraint.

The real top three: build, optimize, review

For us, the data maps cleanly to the three things production agent teams need most:

1. Build agent workflows

Builders need to compose prompts, tools, memory, files, code execution, approvals, and subagents into workflows that are understandable and testable.

The goal is not just “call an LLM.”

The goal is to build a system that can do useful work repeatedly.

2. Optimize latency and cost

Agent systems need model routing, context discipline, caching, parallelism, and observability into where time and money go.

The question should not be:

Which model is cheapest?

It should be:

What is the cheapest reliable path to the outcome?

3. Review and ship safely

As agents generate more work, humans need better ways to inspect intent, diff, risk, tests, and evidence.

The future of agentic development is not “no review.”

It is better review.

That is the layer AdaL is focused on: helping teams build production agents, optimize their behavior, and review agent-generated work before it ships.

New to AdaL? Build production agents with AdaL →

What this says about the agent market

The first wave of agent products was about possibility.

Can an agent browse? Can it code? Can it call tools? Can it run a workflow? Can it remember? Can it use a computer?

The next wave is about production.

Can it be trusted? Can it be measured? Can it be reviewed? Can it be deployed? Can it be optimized? Can it satisfy enterprise constraints? Can it keep working after the demo?

That is why the breakout topics at Claws Out were so telling:

Agent Reliability & Deployment
Infrastructure & Cost Optimization
Enterprise Readiness & Auth Patterns

Those are not hype topics. Those are adoption topics.

The uncomfortable truth

The interesting failures still do not get written down enough.

But when 256 confirmed builders tell you what they are blocked on, the pattern is hard to miss:

Agents are easy to demo and hard to trust.
Agent loops are easy to start and hard to optimize.
AI-generated work is easy to create and hard to review at speed.

That is where the next generation of tooling needs to focus.

Not just bigger models.

Better systems around the models.

Closing

Thank you to GMI Cloud and WorkOS for hosting a room where builders could talk about the messy middle: the failures, constraints, and production blockers that usually stay private.

And thank you to everyone who wrote down the hard thing they are working through.

That is where the real product roadmap lives.

If you are building agents and wrestling with reliability, latency, cost, review velocity, or deployment, we are building for you.

→ Build production agents with AdaL

The Top Production Blockers for AI Agent Builders

Subscribe to the Source

Comments