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.
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% |
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% |
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.