Agent-heavy company10 humans and about 80 agents7 min read

Fieldnote And The Eighty-First Worker

Amara is the invisible eighty-first worker, spending each morning coordinating agents that repeat failures and hide stale context inside successful runs.

Composite future scenario · Not a current customer claim or MVP description

Amara is surrounded by overlapping agent workflows, duplicate work, and one malformed API response.
Eighty agents create an eighty-first job: keeping their private operating instructions coherent.

Fieldnote had ten employees and roughly eighty specialized agents. Some ran every hour, some once a week, and some only after a human approved a task. They collected feedback, researched markets, maintained integrations, tested releases, drafted help content, and prepared operational recommendations.

The eighty-first worker was not another agent. It was the invisible coordination burden carried by Fieldnote's operations lead, Amara.

Every agent had instructions somewhere. The research agents had prompt files. Maintenance agents had retry logic in code. Content agents had brand guidance in a workspace. When an API changed, three agents could discover the same failure separately. When Product changed a definition, downstream agents did not all receive it. Amara spent mornings reading successful run summaries because she could not tell which success hid stale context.

Fieldnote's onemind treated each agent as an Intelligence with a human owner, Project membership, model and adapter version, allowed sources, permitted actions, spending limit, schedule, and kill control. The Mind did not give every agent shared conversational memory. Workflows passed typed artifacts with provenance and approval state.

One Monday, the feedback-analysis agent found eighteen messages in which customers misunderstood an integration limit. The collection agent had stored each message with consent, sensitivity, product area, and retention metadata. The analysis agent received de-identified text and the accepted feedback taxonomy. It proposed a lesson: customers expected historical records to synchronize, while the integration supported new records only. The proposal included evidence, confidence, and two counterexamples.

Nothing changed automatically. The product owner reviewed the evidence, narrowed the lesson to one integration, and accepted it. onemind's dependency preview proposed four downstream changes: help documentation, onboarding copy, a support troubleshooting branch, and a product backlog item. Each had a different owner.

The documentation agent received an approved task package and was allowed to update a draft automatically. The content package contained the accepted product fact, audience, brand rules, source references, and a prohibition on claiming that historical sync was planned. The support agent received the troubleshooting explanation. The product-planning agent received the backlog proposal but could not add it to the committed roadmap without product approval.

That afternoon, a maintenance agent encountered a known 429 error from a partner API. Its onemind package contained the tested recovery workflow: exponential backoff, maximum three retries, a five-dollar run budget, and an escalation rule. A runtime hook evaluated those limits before each retry.

Amara and an integration owner resolve one meaningful exception while routine agent work continues within limits.
Humans review the exception and the decision it requires, not every ordinary success.

The first two retries failed. During the third, the partner returned a malformed success response. The agent attempted to continue, but the hook recognized that required fields were absent. It stopped the workflow, preserved the current state, and opened an exception containing the package version, input artifact, API responses, cost, retry history, and related failed-approach entry. The agent could not increase its retry count or request broader API access for itself.

Amara saw one high-severity exception, not three failed runs and forty success messages. She assigned it to the integration owner. When two more agents encountered the same malformed response, onemind deduplicated them into the existing incident and increased the affected count. The integration owner updated the recovery parser and added a test. onemind rebuilt the maintenance packages and replayed only the idempotent failed steps.

A week later, a different operations agent began creating duplicate CRM tasks after a configuration error. Amara used the Project-level kill switch. Executable Operations actions stopped, while read-only Mind access and audit data remained available. The team corrected the configuration, simulated the workflow against recorded inputs, and restored actions gradually.

After two months, Fieldnote no longer required humans to read nearly every routine run. Humans reviewed all consequential exceptions and a risk-based sample of success. High-severity missed exceptions remained at zero during the measurement period. The company also spent more on telemetry and artifact storage than before, and Amara had to tune noisy rules weekly.

The agents had not become a self-managing company. Product decisions, money, customer commitments, and policy still belonged to named humans. onemind made the delegation legible: every agent knew the relevant part of the company's way of working, every consequential action was limited, and every exception arrived with enough history for a person to decide what happened next.