XMarts room

Spring 2026

BentoLabs AI

Monitoring and learning layer for long-running agents

Visit website

What they do

monitors long-running agents, finds silent failures and suggests fixes

How close to us

4, very close

detects silent failure and root cause for agents; checks only, buyer is an engineering team

Wedges

  • W2 Seeing whether your AI agents actually produce direct
  • W1 Trusted 24/7 coding for small startup teams adjacent
  • W8 The other 90% of an AI skill adjacent
L1 Company brain (knows the organisation) 1, light
L2 Agent team (runs agents, tools, approvals) 0, none
L3 Does and learns (finishes, checks, measures, updates the brain) 2, clear

Who buys

Firm size
not known
Buyer type
developer
Role
head of engineering or the engineer who runs agents in production
UK
not known
Their own description (from YC)

BentoLabs is the monitoring and learning layer for long-running agents. We detect when agents silently fail or drift from the user's goal, system prompt, or tool contracts, show affected users and root cause, and suggest the prompt, skill, or harness fix.

As more teams deploy agents, keeping them reliable in production becomes mission-critical. Bento sits directly in the production loop and gives teams the operational leverage required to scale agent ecosystems without scaling human firefighting alongside them. The result is a system that turns opaque agents into agents that can be monitored, debugged, and improved continuously.

The founders learned this problem at Emergent (YC S24), where they built and operated production coding agents used by 5M+ users. Abhinav was hire #1 and helped Emergent hit SWE-Bench #1 and scale from $0 to $100M ARR in just 8 months. Kaushik was hire #2, led full-stack engineering at Emergent, and was key to building the infrastructure that made production agents reliable, observable, and debuggable. Bento's self-learning engine has also lifted ARC-AGI-3 (internal) by 2.6x and Terminal-Bench 2.0 (internal) from 42.2% to 52.4% pass@1 with the same model, tools, and budget.

Full teardown

BentoLabs AI (YC Spring 2026): teardown vs XMarts

In one line: Bento watches AI agents that are already running in production, flags when they fail without anyone noticing, and then turns each fix into a reusable "skill" so the agent does better next time [site] [yc]. Threat: 2, because it is the same problem as W2 for a similar buyer, but it is five people, has no named customer and stops at monitoring plus fixes [yc] [site].

1. Fact file

Item Finding Source
What they say "Production infrastructure for AI agents." Tagline: "Monitor what runs. Improve what fails. Compound learnings." YC line: "Monitoring and learning layer for long-running agents." [site] [yc]
Founded, team, funding Founded 2026, YC Spring 2026, 5 people, Bengaluru (YC page). One search summary says San Francisco: UNVERIFIED. Funding is not disclosed by them. Two aggregators list about $500K to $595K (not confirmed, and it matches the standard YC deal). [yc] [press]
Founders Abhinav Soni (hire #1 at Emergent, YC S24; they claim he helped reach SWE-Bench #1 and $100M ARR in 8 months) and Kaushik ASP (hire #2 at Emergent, led full-stack engineering). What YC likely saw: two early hires who ran production coding agents for a company with 5M+ users (they claim) (inference). [yc] [site]
Customers None named. The launch post says they work with "teams at unicorn scale". The About page says "Trusted by unicorns". No logos, no case study. [yc] [site]
Price Not public. Usage-based, tied to traces ingested and skills promoted, no per-seat price. Free tier for solo developers, a startup tier, and enterprise pricing by trace volume. No numbers. No job ads, so no sales-model hint. [site] [yc]
Path No renames or pivots found. Blog starts 18 Apr 2026. Newest posts (Jun 2026) move from "self-learning agents" to "catch and fix silent regressions". SOC 2 Type II "in progress". [blog] [site]

2. Their proposition, reverse engineered

Part What they do
Who buys An engineering team with an agent already live in production. Setup takes "an engineer for an hour" [site]. Third-party listing adds payments, compliance and customer operations teams (inference from that listing) [press].
The pain Prompt changes, model swaps and new tools ship as regressions that customers find first. Traces, evals and fixes sit in separate tools [site]. "Most production agents fail silently." [yc]
The promise Know when an agent silently fails or drifts, see who is hit and why, get a fix. Lessons carry to the next run, so "Run 101 is measurably better than run 1" (their words) [yc].
How it works OpenTelemetry tracing. You describe a failure in plain English and Bento trains a "signal" on your traces. Alerts group into incidents. Fixes are "artifacts" (skills, subagents, tools) that move from candidate to promoted as they perform. "The Book" is a plain-language memory of failures, fixes and outcomes [site]. Learnings that help are kept, ones linked to confusion are demoted [blog].
The output Alerts to Slack, PagerDuty, email or webhooks. A root cause. A suggested prompt, skill or harness fix. Versioned, diffable, reversible changes [site].
Proof style Benchmark lifts, not customer results. Terminal-Bench 2.0 pass@1 from 42.2% to 52.4% (internal, 38 tasks, p < 0.05). ARC-AGI-3 score 2.6x, cost per success down 34% (internal). They publish caveats, including 3 tasks that got worse [blog].
Who sells it Demo booking and founders' email. No sales team visible. No open jobs [site] [yc].
Price model Usage-based, no seats [site].
The story Enemy: "vibe-coding" fixes that patch the few runs you pasted in, not the other 999 [site]. Belief: production agents need research infrastructure, not iteration [blog].

3. Positioning

  • Category they claim: closed-loop platform for shipping self-improving agentic systems; "monitoring and learning layer" [site] [yc].
  • Category a YC partner would put them in: agent observability and evals for engineering teams, one step past LangSmith and Langfuse (inference). A third-party listing frames them against those tools [press].
  • What they want to be known for: the layer that stops agents failing quietly and makes each fix stick.
  • Where they sit on the map: layers L1/L2/L3 = 1/0/2, buyer = unknown size, developer.

4. Three layers vs ours

Layer Them (score + evidence) Us (Marton's logs show)
L1 Company brain 1. "The Book" is a memory of failure patterns and fixes for the agent. It is not a memory of the organisation [site]. A vault of about 1,400 pages, 112 call transcripts and about 8,700 customer quotes.
L2 Agent orchestration 0. They do not run or route a team of agents. They sit beside the customer's agent and watch it [site]. An oversight "nudge" during a run exists in a benchmark setup only [blog]. About 5,600 jobs run by agents from three makers, each checked by a different AI before merge.
L3 Execution and learning 2. They measure results and promote or demote fixes, and fixes are injected into later runs [site] [blog]. The work itself stays with the customer's agent, and the product suggests fixes for a human to apply (inference from "suggests") [yc]. About 160 failure records, each with an automatic check. Offer feedback lines fell from 44 to 18 as 22 rules were added. Only about 15% of jobs reached the main code.

5. Same and different

Topic Same or different Them Us
Core belief Same Agents fail silently and teams need to see it [yc]. W2 starts from the same line (brief).
Learning from failure Same Fixes become reusable skills, scored on later results [site]. Marton's logs show every failure gets a record and a check; skills have upkeep loops (W8).
Buyer Similar Engineering team with agents in production [site]. W2: teams running Codex or Claude Code in loops (inventory). No customer yet.
Where the agents run Different Customer's own agents, traced with OpenTelemetry [site]. The agents are ours, run by our queue. Not yet decoupled for others (inventory).
What the failures are Different Product behaviour: prompt drift, tool contract breaks [yc]. Fleet behaviour: stuck queues, jobs that never merge, silent cost burn (inventory).
Proof Different Benchmark lifts [blog]. Counts from one operator's logs: jobs, incidents, merge rate. No customer number.
Size and speed Different Five people, a live product with free tier, setup in an hour [yc] [site]. Two founders, a system on three Macs. Not installable by a stranger yet (inventory).
Honesty about limits Similar Posts list their own regressions and tiny sample [blog]. Marton's logs list weaknesses in the inventory.
Price Different Usage-based, free tier [site]. Not set.

6. Wedge overlap

Wedge Fit Why
W2 Seeing whether your AI agents actually produce direct Same problem: find silent failures, root cause, what is stuck [yc]. Same buyer, a team running agents. They cover customer-facing agents in production; W2 as written also covers cost and "is the fleet producing" (brief).
W8 The other 90% of an AI skill adjacent Their artifacts are skills that get promoted or demoted by measured results, and versioned [site]. That is part of skill upkeep. They do not claim data freshness, retirement or company-wide reuse (UNVERIFIED that none exists).
W1 Trusted 24/7 coding for small startup teams adjacent Their benchmark is coding-agent tasks [blog] and the founders ran coding agents at scale [yc]. They do not run the coding; they watch and improve it.

7. Whitespace (where they stop)

  • Layer gap: they watch and suggest. They do not run the agents, hand work between them, or gate what is merged [site] [yc]. To own it we need one customer's agent team run end to end with a before/after number.
  • Buyer gap: the product is built for agents inside a customer's production system, wired by OpenTelemetry [site]. Small teams running coding agents on their own machines are not mentioned (inference). To own it we need 3 to 5 such teams who say the pain is real.
  • Number gap: public proof is benchmark pass rates and cost per success, not money saved or hours won by a customer [blog]. To own it we need one customer number a founder would sign.
  • Price gap: not a gap. A free tier and usage pricing are already public [site].
  • Speed gap: not a gap. They claim setup in about an hour [site].

8. For the YC application

  • Proven today: Marton's logs show five months of running a fleet of coding agents: about 5,600 jobs, about 160 incident records with names for the failure classes, a heartbeat for what is stuck or silently stopped, and a cost meter after one launch used 39% of a week's AI budget in 14 hours. Bento's public proof is benchmark lifts and no named customer [blog] [site].
  • Draft answer to "how are you different from BentoLabs?": DRAFT. "Bento watches an agent after it is built and suggests fixes. We run the whole agent team and check each piece of work before it counts, and we have five months of real failures from doing it." Founders say it their own way.
  • Future claim (needs proof): "We find why your agent team stalls, fix it, and show the saved hours." Needs one outside team's coding agents run for 4+ weeks with a before/after number, and the failure tracking decoupled from our own queue (inventory).
  • What we understand that they don't: the pain of a coding-agent fleet is mostly things that never finish or never land, not wrong answers. proven as our own experience (inventory); needs proof that other teams feel it.
  • Copyability (M3): easy. Silent-failure detection and fix suggestions are their core product, so adding "stuck work", "never merged" or "cost burn" signals is a feature for them. They already let a user define a new failure signal in plain English [site]. Their founders ran coding agents, so they would want it (inference). Not hard, so M3 can not score above 3 against Bento.
  • Why now (M4): None found. Do not use "more teams run agents": that is general AI progress.
  • Do not claim: "nobody watches agent fleets" (Bento and others do). "Self-learning agents" as our headline (Bento owns that frame with benchmark numbers). Any cost or merge number as a product result (the inventory marks merging as unreliable this month). Any outside user (nobody has run the system but Marton).

9. Ideas worth taking

  1. Publish the caveats with the results, with raw traces. It builds trust fast with engineers [blog].
  2. Describe a failure in plain English and have the tool turn it into a live check [site]. Matches how a non-coder founder would want to use it.
  3. Score each fix by what happened after it shipped, then demote the ones that hurt [blog]. Same shape as our "rule from a failure" loop, with a number on it.

10. Unknowns

  • Who their paying customers are, and whether any pay. Look for a launch thread, a case study or the founders' posts.
  • Real price. Ask a buyer who has seen a quote.
  • Whether they run or only watch coding agents. Check their newest posts and demo.
  • Their location (Bengaluru on YC page; San Francisco in one search summary) and any UK or European customers.
  • Funding: aggregators disagree ($500K and $595K); no primary source.
  • Whether fixes apply automatically or a human approves each one.

Sources

Technical detail
Slug
bentolabs-ai
Lens hash
179096c479
Pass
deep
Stale
no