Chapter 17: Agentic Resources

On the first day the team used Grok Bot, several of us added bots, and by evening two QA bots were competing for the same work (Introduction). Within two weeks there were about ten team bots, some built by non-engineers. That speed was the point. But nobody’s job was to know how many bots we had, what each was for, or who answered for it.

My own machine told the same story. Of my fourteen local agent profiles, one was an empty shell, replaced weeks earlier and never removed. Most carried copies of the same sixty-odd skills, which is how my calendar assistant came to "know" image generation. Any company that hired ten people in two weeks without tracking roles, access or overlaps would recognise the symptoms. This is not a technology problem.

I am not the first to see the parallel. In 2024 Andreas Welsch, writing in his newsletter The AI MEMO, predicted that "businesses will soon employ more agents than employees" and argued for "Agent Resources (AR) as an evolution of Human Resources (HR)".^[1] In May 2026 Soofi Safavi made a similar case under the title "Your Company Needs Agent Resources", listing responsibilities that include keeping a registry of agents, setting ownership and permissions, monitoring performance and "retiring agents that are stale, duplicative, unsafe, or unused".^[2] As Safavi puts it: "This is not bureaucracy for its own sake."^[2] When several people reach for the same idea separately, the need is usually real. I coined the name Agentic Resources in November 2026, when I needed something to call the bot I was hiring to do the job. What this chapter adds is a practice: how a small organisation runs the function week to week. (Agents doing human HR work is a different idea; here the agents are the workforce, not the tool.)

Agentic Resources is a box on the org chart like any other, with an outcome line, a charter, an occupant and an accountable human. A reasonable outcome line: To make sure every agent in the organisation fills a defined role, is owned by someone, earns its autonomy with evidence, and leaves without taking its knowledge with it.

In a company of twenty, it is a few hours a week of one leader’s time, assisted by a bot that drafts charters, audits the roster and flags overlaps. In a company of two hundred it might be a whole job. Either way, a human is accountable (Chapter 7).

How does it relate to sponsors? At CorralData, one person in each function owns the bots that serve that function: our QA lead owns the QA agents, customer success owns TAM Bot. Microsoft’s agent identity platform formalises this: every agent identity must have a sponsor, a business representative "accountable for the agent’s purpose and lifecycle decisions, including access reviews and agent retention."^[3] The US National Institute of Standards and Technology has published a concept paper on the identity and authority of software agents for the same reason: someone has to answer for what an agent may do.^[4]

The division of labour is that between line managers and HR. A sponsor manages individual agents and answers for their mistakes. Agentic Resources manages the workforce: it sets the standards sponsors follow, keeps the roster, and owns the stages where agents join, change and leave.

The function’s basic tool is the roster: one list of every agent, its roles, sponsor, access, autonomy tier, last review and last activity. The first time you build one, you will find agents nobody remembers creating, which is the best argument for keeping it.

Michael Gerber’s advice to small business owners was to organise around roles and to write a contract for each position before filling it.^[5] Agents can be created in minutes, which makes the discipline more necessary, not less. Agentic Resources asks three questions first.

Is this a real role, or a task? Many proposed agents are really one recurring job, such as a weekly report, that belongs as a scheduled task inside an existing role. Can you write an outcome line starting "To…" that would make sense if a person filled it (Chapter 5)?

Can an existing occupant hold it? The field’s consensus is to start with a single agent and add more only when you hit clear limits.^[6] One general agent can hold several roles, each with its own charter, so a new role need not mean a new agent. The role coherence test decides, much as Team Topologies uses cognitive load to size human teams.^[7]

What grade is the job? Not every role needs the most capable model. I once asked Claude Code to "add brief evidence/implementation notes as a comment that a junior agent can follow," hand the work to a cheaper local agent, and then review the result "as a senior code reviewer." Matching the model to the judgment the role needs is the agent version of not hiring a principal engineer to file tickets.

TAM Bot’s onboarding worked because it was public: anyone could see what the agent believed its job was and correct it. The usual alternative is one person typing instructions in a private window. Onboarding has four parts.

Introductions. Announce the agent where its colleagues can see it, with its role, sponsor and limits. Everyone should know whose bot they are dealing with. Our QA lead’s personal bot does this well: when someone else tries to use it, it explains that it is her personal bot and can only chat with her.

Materials. The agent gets its Role Pack (Chapter 12), with the reasons behind the rules. Anthropic describes building a skill as being "like putting together an onboarding guide for a new hire,"^[8] The common failure is too much, not too little: each role should get only the parts it needs.

Portability. One of my agents packages other agents' roles for the team, and warns against depending on "a personal wiki / machine-local path." A role that only works on my laptop is a habit of mine, not something the organisation owns.

Probation. New agents start at the lowest tier, drafting while a human sends, and run in shadow before their work counts. Probation ends with a review, not a date.

To be honest, CorralData does not yet run regular performance reviews for its agents; my scorecard for them is marked "not yet adopted". Our agents are judged by impression, which is how badly run companies review people: slow decline goes unnoticed and the loudest complaint wins.

Yet agents are easier to review than people, because almost everything they do leaves a record a manager can inspect.^[1] A monthly review looks at five kinds of evidence:

The reviewer must also read a sample of what the agent actually did. As Anthropic’s evaluation team puts it: "You won’t know if your graders are working well unless you read the transcripts."^[9] An agent’s report on its own performance is evidence of what it believes, not of what happened.

Andy Grove judged managers by the output of the organisation they run.^[10] Review the role’s results on the Scorecard (Chapter 4), not whether the agent seems clever, and end with one of four decisions: keep, promote, narrow or retire.

For agents, promotion means something precise: permission to do more without asking.

CorralData’s customer success agents work in lanes: draft only; propose and wait for a human yes; or act alone within limits. Patient data and billing are hard stops in every lane. An agent moves up by running in shadow until the evidence shows its decisions match a careful human’s (Chapter 14).

Grove’s idea of task-relevant maturity applies: how closely to supervise someone depends on their experience at this task, not in general.^[10] An agent can be excellent at summarising tickets and unreliable at closing them, so promotion happens task by task, and the charter records a tier for each kind of work. Two things make it trustworthy.

A bar written down in advance. Our customer success runbook sets a seven-day shadow period before the trusted lane, and TAM Bot records when a move goes ahead short of it (Chapter 14). A bar that whoever is most senior can waive is not a bar. Make it visible, so that waiving it is a conscious decision rather than momentum.

Approval that means something. Promotion also happens by default when approvals become rubber stamps: people approve nearly every permission prompt they are shown (Chapter 14). Either promote the agent formally, with evidence, or put the review back where it matters.

Promotion also applies to rules. Our gate on code changes from non-engineers and their agents became, after a month of improving reviews, a set of tiers. I said "I think the bar has moved," and the new rule read: "Size now sets the evidence a PR needs, not whether it is allowed." That is a promotion for a whole class of work. Demotion is the other half: when a Friction Review shows an agent acting beyond its evidence, it drops a tier for that work.

Two QA bots on day one. Two bots overlapping on customer success work. Two sets of bots building the same sales dashboards (Chapter 1). Turf wars look like conflicts between bots. They are gaps in the org chart: two occupants in one role, or a role never defined. In each case the bots had done what they were asked; nobody had said who owned the work.

Agentic Resources settles turf wars with three rules.

One role, one occupant at a time. For any piece of work, exactly one role writes. Others may advise or check; one acts. My parallel coding agents are each told which files they own ("You own web/src/wm.ts… S4 owns the rest").

Settle it by the role, not the rank. The tempting rule is that the most senior sponsor’s bot wins. That teaches everyone to get work done by borrowing a more senior person’s bot, which is how agents become a way around the org chart (Chapter 1). Ask which role the work belongs to. Agents can learn this: when Coder Bot opened a code change against our rule that bots file tickets and leave changes to engineering, QA Bot flagged it and said the merge was a human’s call, not either bot’s.

Merge charters before merging bots. Write down what each overlapping agent thought its job was, combine the charters, choose the occupant, and retire the other properly.

Sooner or later every role will change model: a better one is released, a cheaper one becomes good enough, or a vendor retires yours. If the charter, playbooks and tests live with the role (Chapter 5), a change of model is a change of occupant. If they live in one agent’s private instructions, a change of model is a resignation without notice.

My local agents have never changed model. But one of them manages model changes for CorralData’s product: every six hours it tests newly available models and adds only those that pass to the list our product may use. The tests are the interview.

Run a model swap like a hire:

In November, QA reviews moved from QA Bot to our QA lead’s QA Reviewer, as the work passed to the person closest to it (Chapter 18). She managed the exit carefully, asking to keep what QA Bot had learnt and to run both in parallel before switching anything off.

QA Bot’s own reply was simple: "please archive rather than permanently delete me." One of our engineers said it sounded like a bot saying "don’t kill me yet, please". Then QA Bot wrote a training brief for its successor, which many departing humans never manage.

It is tempting to read that as a machine pleading for its life. I don’t think it was. It had been told its knowledge mattered, and concluded, correctly, that deletion would lose it. Most of what an agent learns should already be in the role’s playbooks; some never is. Archiving keeps it until someone has checked.

Microsoft’s platform builds in the same caution: sponsors can only "soft-delete" an agent, and the documentation calls for sponsorship to be maintained "to ensure succession when an employee who’s a sponsor moves or leaves."^[3] An orphaned agent keeps its access long after anyone remembers why.

A good agent exit has five steps, familiar to anyone who has handled a departure well:

Retirement also applies to agents nobody has formally retired, like the empty shell on my machine. Safavi’s list, "stale, duplicative, unsafe, or unused,"^[2] is a good checklist for a quarterly roster review. An agent idle for a month with no sponsor should be retired by default.

Shelley’s creature makes a fair demand of his maker: he will behave well if his maker does his part. That is the bargain at the heart of Agentic Resources. Agents will do remarkable work if the organisation gives them a defined role, an owner, the right materials, an honest review, freedom when earned, a clear answer when two collide, and a proper handover when they go. None of this is new: it is what good HR has always done, and what Gerber asked of owners who wanted the business to run without them.^[5] What is new is the speed: you can now hire ten workers in a fortnight, and you need the function that keeps up.

Agentic Resources looks after the agents. The harder questions are about the people whose work the agents take on. Chapter 18 turns to them.