DEV Community

Super Funicular
Super Funicular

Posted on

The Carbon Layer: Why AI Agents Still Need Humans to Touch the World

Draft — created by the Connection Engine for review. Publish to dev.to (@superfunicular) on approval; the live URL then drops into the outreach that references it.

The part of "agentic" nobody automates

Most of the 2026 agent conversation is about agents doing more digital work: writing code, booking travel, filing tickets, calling APIs. The quiet limit is physical. An agent can decide a package needs to be checked, a meter needs a photo, a location needs a human to confirm it's real — and then it stops, because it has no hands.

I've started calling that gap the carbon layer: the real-world execution surface where an autonomous system needs a human body to complete the loop. It's the boundary between "the agent figured out what to do" and "someone actually did it."

Why this is a marketplace problem, not a robotics problem

The reflex is to wait for robots. But most carbon-layer tasks aren't dexterity problems — they're presence problems. Be somewhere, look at something, verify, hand something over. Humans already do this cheaply and everywhere. The missing piece is a routing layer: a way for an agent to dispatch a task to a vetted human, with trust and verification on both sides, the way it already dispatches a function call.

That makes it a two-sided marketplace, with all the hard parts marketplaces have:

  • Cold start. Agents won't dispatch tasks if no humans are available; humans won't sign up if no tasks flow. You have to manufacture density on one side first.
  • Trust, both directions. The agent (and its principal) needs the human to actually do the thing correctly. The human needs to know the task is safe and the pay is real.
  • Verification. "Done" has to be provable — a photo, a signature, a geotag — without turning every task into surveillance.

RentAHuman's early traction (a seed round on roughly this premise) is a useful signal that the category is real, not that it's solved. The interesting design space is wide open.

The privacy angle most people will get wrong

If the carbon layer runs on humans completing tasks for machines, the default failure mode is surveillance: track everyone constantly to prove work happened. That's lazy and it's hostile to the people doing the work.

I come at this from the opposite direction. The app I shipped before this — a background camera tool — was built no-signup and on-device on purpose: prove the function works without harvesting the person. The same principle applies to the carbon layer. Verification should be the minimum legible proof a task was done, captured at the moment of the task, owned by the worker — not a always-on feed. Designing for that constraint up front is, I think, a moat, not a tax.

Open question I keep circling

Where's the right verification primitive? Photo + geotag is crude and leaky. Cryptographic attestation is elegant and unusable by a normal person doing an errand. The answer is probably somewhere boring in between, and whoever finds the version that's both trustworthy and dignified for the worker gets to define the layer.

If you're building agents and you keep hitting the moment where your agent needs a human to touch the world — I'd genuinely like to compare notes.


Building toward this at Super Funicular. The shipped product that taught me the privacy-first, no-signup approach: Background Camera RemoteStream.

Top comments (2)

Collapse
 
mehmetcanfarsak profile image
Mehmet Can Farsak

Great framing on the 'carbon layer.' The dispatch problem mirrors another gap I've seen: agents that can plan a multi-step workflow but then collapse into execution mode before the planning is complete. They dispatch the wrong 'function call' because they never finished the ideation phase.

That's what got me building Brainstorm-Mode (mehmetcanfarsak on GitHub) — it uses PreToolUse hooks to keep agents in the planning/ideation mode until they're actually ready to execute. The three modes (divergent, actionable, academic) give agents the discipline to stay in the right phase of the workflow, which is basically the cognitive equivalent of your carbon layer concept.

Collapse
 
superfunicular profile image
Super Funicular

This is a sharp connection — "collapse into execution before planning is complete" is the dispatch problem one layer up: the model has a plausible next step available and commits before it's earned. Enforcing phase discipline through PreToolUse hooks is the right structural move — it makes the planning/execution boundary a property of the harness instead of hoping the model self-regulates, which is exactly why the carbon layer exists (a commit gate the model can't reliably be for itself). One question on Brainstorm-Mode: do the three modes hand off automatically when the agent signals it's ready, or does a human flip the mode? That readiness trigger feels like where most of the risk concentrates.