How do you prevent a sprawl of unmaintained internal agents?

Prevent internal agent sprawl by making continued operation a decision someone can review. Keep a maintained inventory of what exists, compare apparently overlapping agents against their actual work, and assign capacity for shared maintenance and deliberate retirement. An agent should not remain in service merely because nobody has decided what to do with it.

The aim is a supportable portfolio. A small collection can still contain unknown access, abandoned experiments and unowned dependencies. A larger collection may include legitimate local variants. Start with the work and the operating commitment before choosing a target agent count. The tools and workflows guide places that decision alongside what to automate and support.

Establish what the inventory actually represents

Suppose Jamie Lee leads IT operations at a 450-person commercial property-services company. Two office sites use internal agents to triage routine cleaning requests. Each consults its site's approved service catalogue and permitted request records, then proposes a receiving facilities desk. A person decides what to dispatch. Neither agent authorizes spending or makes safety decisions.

Jamie also finds a training copy from an earlier pilot and a separate tool used for a quarterly supplier-contact check. The immediate task is to establish which of these are operating services, experiments, copies or records of the same underlying agent.

Microsoft's October 2026 agent-registry documentation provides a useful warning about counting. The same Copilot Studio agent can appear under different publisher types, with separate lifecycle records. Removing one entry does not remove the other. The documentation also notes that publishing alone may not make an agent visible in that admin centre. These are product-specific behaviors, not a discovery guarantee for every platform.

Reconcile the inventory with the people and systems involved. Ask authorized administrators about supported platform records, deployments and scheduled work; ask business teams which agents they rely on. Record the environments and surfaces examined, along with known gaps. A list covering one platform should not be labelled the complete company inventory.

For each distinct running arrangement, retain enough information to make a decision:

• Work and audience. The task, intended users, permitted result and important exclusions.
• Implementation reference. The underlying agent, deployed versions, environment and related publisher or channel records.
• Authority and dependencies. Relevant information access, permitted actions, shared components and systems or people that depend on its output.
• Operating commitment. Business owner, technical support, unresolved work and a usable fallback.
• Current evidence. Last meaningful activity, latest evaluation, known restrictions and the next review or change trigger.

Keep credentials in the approved secret-management system rather than copying them into this register. Link to controlled operational records where appropriate. Give the inventory a maintainer and update it when an agent is created, shared, changed, restricted or retired.

The voluntary NIST AI Risk Management Framework Playbook recommends defined responsibility and policies for maintaining an AI-system inventory. Its purpose here is practical: the record should help Jamie identify affected work and responsible people, rather than serve as a one-time census.

Compare agents by their work before consolidating them

The two cleaning agents may look redundant in a list. Both accept a request and suggest a facilities desk. But one site may have a different service agreement, source collection or permitted audience. Combining them without examining those boundaries can change who sees client information and which work is routed where.

Compare the proposed alternatives on the same dimensions:

A shared label is weak evidence of duplication. Equally, a different name or prompt does not establish a useful difference. Ask each owner to show the distinction through real requirements and approved test cases.

Cohere's October 2026 discussion of agent sprawl argues for allowing a challenger variant to compete with an incumbent in a bounded comparison. That is a vendor's proposed operating approach, not a demonstrated result for Jamie's company. It usefully challenges a blanket ban on alternatives: experimentation can test whether another design is better, provided someone owns the comparison and its ending decision.

Give a challenger a defined question, permitted exposure and review point. Decide whether to replace the existing route, retain separate scopes or stop the experiment. Use the agent-evaluation guide for task outcomes and exceptions. Avoid turning a temporary comparison into two permanent services by default.

Make shared maintenance visible

Consolidation is not the only way to reduce repeated work. Jamie's two site agents can retain their local information boundaries while using a maintained reference that defines common request categories. That shared reference still needs an owner, version and change process.

If the common definition of a cleaning request changes, both site routes may need checking. The receiving desks and site-specific service rules remain separate. The shared dependency helps Jamie find the affected agents; it does not establish that the update is safe for both.

Group maintenance around meaningful dependencies. Ask what must happen when a shared reference, connection, component or platform changes, and which owner accepts the resulting work. Retain local acceptance cases where conditions differ. Sharing a component can reduce duplicated implementation work while concentrating the consequences of a faulty change.

A portfolio review should therefore examine more than the number of agents. Keep separate observations of:

• Unsupported operating arrangements.
• Overdue material changes.
• Unresolved exceptions.
• Shared dependencies without a maintainer.
• Experiments without a decision date.

Report what each observation covers and what remains unknown. None is a universal risk score.

Microsoft's agent-lifecycle guidance, updated in October 2026, connects monitoring with improvement or retirement as knowledge, use and integrations change. It is operating guidance, not evidence for one mandatory review interval. Choose review triggers according to the actual work, alongside scheduled checks that the team can carry out.

Fit the portfolio to the support people can provide

Maintenance consumes time even when no new agent is being built. In an August 2026 Reddit discussion, a user reported that they and two colleagues had spent hours that week manually reviewing an agent inventory. They described their own inactivity-based housekeeping policy and asked how others managed the work. Replies suggested automation, but the author's follow-up still questioned the licensing route. No successful automated outcome was established.

The employer, company size and results are unverified. The concrete lesson is that a lifecycle policy can create recurring work which someone must perform. Their chosen inactivity threshold is not a standard to copy.

For Jamie, list the actual commitments before accepting another operating service: reviewing changes, checking exceptions, maintaining dependencies, answering users and completing planned retirement work. Compare those commitments with available skills, time and coverage. A nominal owner who cannot undertake the work leaves the gap intact.

When capacity is insufficient, make the consequence explicit:

• Keep the supported scope smaller while the team repairs a gap.
• Share maintenance that can genuinely be shared without merging inappropriate access or requirements.
• End an experiment whose question has been answered and whose continued operation is unsupported.
• Retire a service that is no longer needed, after handling its remaining obligations.

The individual-agent ownership guide covers the receiving people, permissions and handover test. The portfolio decision is which commitments the organization can continue to carry together. For a new prototype gaining real users, use the production-service guide before treating enthusiasm as an accepted support arrangement.

Treat quiet agents as review candidates

An activity timestamp is useful evidence with a limited meaning. Jamie's quarterly supplier-contact check may be quiet between scheduled reviews. A training copy might have frequent test activity without an approved live purpose. Neither case is settled by sorting on last use.

Ask the business owner what work is expected next, who depends on it and whether a supported replacement exists. Check whether the activity record covers every relevant channel and scheduled invocation. Unknown coverage should stay unknown rather than becoming proof of inactivity.

Record a specific decision and its conditions. Retaining the quarterly check requires a current purpose, supported access and a way to verify the next run. The training copy may be a retirement candidate if its purpose has ended, but Jamie must still establish whether anyone uses its link or output. A decision to restrict an agent also needs an owner and a next review, so restriction does not become permanent limbo.

Avoid a portfolio target that rewards deletion regardless of consequence. The useful result is less unsupported work and clearer operating commitments, with important services preserved.

Retire an agent through a checked change

Retirement needs its own evidence. NIST's Playbook cautions against indiscriminate termination and asks organizations to consider dependent systems, continuity and material that must be retained. It does not prescribe a universal retention period or authorize an administrator to erase everything associated with an agent.

For Jamie's obsolete training copy, use a controlled retirement change:

1. Confirm the affected work. Identify the actual agent and its deployments, users, scheduled invocations and downstream dependencies. Resolve misleading duplicate records before acting.
2. Provide the next route. Tell affected users what replaces it, or how the work will be completed. Reconcile pending and uncertain tasks with their receiving owners.
3. Remove its ability to operate through approved controls. Have authorized operators handle the relevant publication routes, schedules, access and connections. Check shared dependencies before revoking something another service needs.
4. Preserve the required history. Follow the organization's retention and investigation requirements for decisions, relevant records and results. Keep the retirement decision linked to the inventory.
5. Verify the intended end state. Check the known entry points, scheduled work and affected users. Investigate unexpected continued activity; document discovery gaps rather than claiming universal proof from silence.

Arthur's retirement guide distinguishes turning off an application from addressing its connections, schedules and retained data. The vendor also emphasizes checking after retirement. Use that distinction without assuming any discovery product sees every execution path.

Jamie can close the training-copy decision when the agreed routes have been handled, unfinished work has an owner and the checked results support the intended restriction or retirement. Keep the record available. It should explain why the agent stopped and what happens if someone still needs the work.

Questions about preventing internal agent sprawl

Does an agent inventory prevent sprawl on its own?

An inventory makes decisions possible, but it does not maintain an agent or supply support capacity. Keep the record current and use it to identify unknown ownership, shared dependencies, unresolved changes and retirement candidates. Check its coverage and distinguish underlying agents from multiple records before reporting counts or taking action.

Should we delete agents after a fixed period without use?

Use inactivity to trigger review rather than assume the agent is obsolete. Confirm the measurement's coverage, expected work cycle, dependencies and replacement route. A quarterly supplier-contact check may legitimately be quiet between runs. If retirement is justified, follow a checked retirement change instead of treating a timestamp as authority to delete.

Should similar agents become one central agent?

Compare the actual task, rules, audience, information access and support needs first. Similar cleaning-request agents at different sites may need distinct client boundaries. They can sometimes share maintained components without sharing all data or authority. Use the comparison questions, then test the proposed arrangement before migrating users.

How often should an agent portfolio be reviewed?

Set a scheduled review appropriate to the work and available support, with additional reviews after consequential changes. A changed source, connection, owner, permitted action or downstream dependency may require attention before the next meeting. Record the decision, unresolved work and next trigger. There is no single interval that establishes safety or usefulness for every agent.

What if nobody can maintain an agent that people still need?

Identify the work and its consequences, then have the responsible business and technical people decide which scope can continue under supervision and what needs a supported alternative. Assign the unresolved maintenance and user handoff explicitly. Use the ownership handover test before a new owner accepts it; changing a name does not create the needed skills or capacity.