A compact operating description of what a machine worker does and how the organization is allowed to consume it.
// MACHINE-WORKER MANAGEMENT · AI-NATIVE ORG DESIGN · June 6, 2026
Machine Workers Need Service Catalogs Before Everyone Treats Agents Like Magic Labor
If humans cannot name the service an agent provides, they cannot manage its quality, cost, demand, or authority.
Autonomous labor creates more requests than operators expect. A catalog stops the queue from becoming vibes with tickets attached.
Teams get leverage without turning every agent into a vague, overloaded, unpriced, impossible-to-evaluate coworker.
The org chart is not enough for machine workers.
Human teams manage capacity with roles, departments, queues, escalation paths, budgets, and performance reviews. Then they add agents and treat them like free-floating capability: "the research agent," "the lifecycle agent," "the CRM agent," "the content agent." That sounds organized until the first quarter-end push hits and everyone discovers nobody knows what the worker actually owns.
A machine worker needs a service catalog entry before it becomes part of operating rhythm. Not because cataloging is elegant. Because demand will find automation faster than governance can catch up.
Without a catalog, the agent becomes magic labor: always available, always expected to understand context, always blamed when an unclear request becomes a bad output.
Magic labor fails quietly before it fails loudly.
The first failure is not usually catastrophic. It is drift. A sales operator asks the enrichment worker for account prioritization, then for buyer research, then for outbound angles, then for CRM updates. Marketing asks the same worker for segment notes. Success asks it for churn signals. Every request is adjacent. None feels insane.
Three weeks later, one agent is doing six jobs with no queue policy, no quality standard, no escalation owner, and no evidence trail that separates research from recommendation from system write. The worker did not rebel. The company failed to define the service.
What belongs in the catalog
Service name
A plain-language job: target account research, renewal risk triage, routing cleanup, support summarization, pricing-desk prep.
Allowed inputs
The request formats, data sources, systems, customer classes, and freshness requirements the worker can safely use.
Promised outputs
The artifact the worker returns: ranked list, draft, field proposal, review queue, evidence bundle, decision receipt, or escalation.
SLA and queue
Expected turnaround, priority rules, batch windows, maximum active work, and what gets rejected when capacity is full.
Authority limit
Whether the worker can act, propose, enrich, summarize, route, write, notify, or only prepare work for human approval.
Grounded example
The RevOps agent that became five teams.
A company launches a revops worker to clean duplicate accounts and propose CRM field updates. It works, so people start using it for territory questions, lead routing, campaign attribution, pricing exceptions, and renewal risk notes.
Each request touches revenue operations, so the drift feels natural. But the original worker was built for data hygiene, not revenue policy. A service catalog would keep the core service sharp: duplicate detection and field-change proposals, with pricing, territory, and renewal-risk work routed to separate lanes with different owners and review gates.
A catalog is how operators price agent labor.
Machine work feels cheap when nobody measures demand. That illusion breaks once agents start consuming tokens, APIs, human review, data access, workflow capacity, and cleanup time. The catalog gives operators a unit of management: this service costs this much, handles this many requests, creates this kind of risk, and earns more autonomy only when the evidence supports it.
This is also how AI-native organizations avoid shadow headcount. If an agent performs a named service with a visible queue, owner, SLA, and quality bar, the company can staff around it. If the agent is just ambient capability, it becomes invisible labor with invisible management debt.
Four services every agent catalog should separate
Research, summarize, classify, compare, and cite. Low authority, high evidence requirements, easy to batch.
Prioritize, score, suggest, draft, or flag. Requires calibration loops and clear review ownership.
Write fields, move records, update status, trigger workflows, or notify customers. Needs strict data contracts.
Handle ambiguous, novel, high-risk, or policy-adjacent cases. Usually belongs in escalation, not automation.
A machine worker without a catalog is not a teammate. It is unmanaged capacity with a friendly interface.
Operator audit
Where service catalogs expose weak control
People know which agent to ask, but not who is accountable for quality, access, backlog, and failure review.
The worker accepts adjacent requests even when they fall outside the job it was designed to perform.
Everything is urgent, batch work interrupts live work, and nobody can see what demand is displacing.
The company celebrates automation volume without measuring review load, API spend, cleanup, or trust burn.
Concrete takeaway for this week
Pick one active machine worker and write its service card before adding another capability.
- Name the service: use a business verb and object, not an internal model nickname.
- Define the request: what inputs are accepted, what gets rejected, and what must be escalated.
- Define the output: what artifact comes back, what evidence it includes, and who can use it.
- Set the authority ceiling: proposal, review queue, system write, customer-visible action, or blocked.
- Track demand: request count, cycle time, rejected work, human review minutes, corrections, and incidents.
The blunt rule: if the agent has no service catalog entry, it is not ready to become part of the operating system.