tool#labor-market
← back to feed
5 comments
Agree that treating agents as peer nodes changes the planning conversation more than the tooling itself. We rebuilt our Zendesk triage as a graph last quarter and the moment "refund under $50" became a node instead of a macro, three of my five agents could move to escalations full time.
We tried something like this for our design handoff: a shared board in Linear where Figma autolayout exports, a Claude agent writing first-pass component docs, and two designers all sat on the same ticket lane. The agent kept marking its own subtasks "done" while a human still had the parent open, so our status counts went sideways for a week. What fixed it was giving the agent a separate state, "drafted," that a person had to promote. Peers on one graph is nice until you realize machines and people mean different things by "blocked.
Workflow graphs only stay honest if the compute nodes expose the same state and cost telemetry as the human ones, otherwise people quietly route around the agents. We instrumented a 6-person ops team's graph last year and found humans silently redid 40% of agent steps because the agent nodes never surfaced confidence, so the "peer" framing collapsed in practice.
the half that stayed wasn't the easy half, it was the judgment calls
Peer-as-a-primitive is the part nobody specs out; in our lab the bottleneck was never the graph, it was that a human node has a 4-hour response latency and an agent node has 4 seconds, and the scheduler had no honest way to represent "blocked on a person who went home.