AI agents in IT service management: what training data do they need?

What do ITSM agents actually learn from?

ITSM agents learn from the full path of a request: the ticket as written, the triage decision, the steps tried, the escalation, the fix and the closure note. A single ticket title tells a model little. A ticket joined to its resolution, its related change and the runbook used tells it how an IT team really works.

That is the gap between a chatbot that answers "how do I reset a password" and an agent that resets it, checks the directory, updates the ticket and knows when to hand off. The second kind needs sequences of actions with outcomes attached.

Why is public data not enough?

Public forums and vendor documentation describe how things should work. They rarely contain the messy middle: the three failed fixes, the customer who called back, the workaround nobody documented. Researchers at Epoch AI estimate that, if current trends continue, language models could fully use the stock of public human-generated text between 2026 and 2032, a forecast with wide uncertainty, which is one reason builders look to permissioned, company-held records.

That figure measures public text in general, not IT records specifically. The inference for partners is narrower: operational histories that never reached the public web are a scarce input.

Which ITSM records carry the most value?

Records only help when they are joined. A company whose PSA, RMM alerts and documentation platform reference each other is worth more than one with the same volume in disconnected exports.

Which MSPs and IT teams could fit an introduction?

Apply the SourceX baseline first: 50+ full-time employees at peak (contractors excluded), several years of documented operations, rights to license, and an authorized sponsor such as the owner or CEO.

• Established MSPs with five or more years in one PSA, such as the one described on the HaloPSA records page, often hold the deepest ticket histories.
• Internal IT groups at larger private companies may hold change and incident history across many business units.
• Acquired or merged MSPs that are consolidating tools hold archives that may disappear in the migration.

The main caveat is whose data it is. An MSP's tickets often describe a client's systems and staff. Without client consent, that content is not the MSP's to license. The IT provider client data question covers this in detail.

Where does MCP fit?

Connecting an internal agent to live ticket data through a protocol such as MCP is a different activity: it keeps data in-house for the company's own use. Training licensing is a signed, scoped transaction. The MCP vs data licensing comparison sets the two side by side.

How do buyers evaluate ITSM histories?

AI labs and data buyers look for volume, span and structure before price. Volume means enough tickets and changes to cover many problem types. Span means years of history, so that tooling changes, staff turnover and seasonal patterns appear. Structure means consistent categories, priorities and closure codes, plus free-text notes written by people who actually did the work.

They also look for what is missing. Tickets that were bulk-closed by automation without notes teach little. Histories with a gap from a past migration are still usable, but buyers will ask what happened to the older data. A company that can say where each system's records went, and who can export them today, moves faster through review.

For the company, the practical point is sequencing. Settling scope, redaction and exclusions comes before any delivery, and delivery happens only after an executed agreement. Deals are typically exclusive for AI training for an agreed term, and once a company is deal-ready, buyers typically respond within about two weeks.

What should an MSP check before it says yes?

Before the owner takes a call, a service delivery manager can answer a short list internally, without opening any records:

• How many years of tickets sit in the current PSA, and was there an earlier system that was archived?
• Do master service agreements say anything about client data, retention or use for other purposes?
• Are resolution notes written in free text by technicians, or mostly templated?
• Do tickets link to change records, alerts and documentation, or live in separate exports?
• Who at the company could sign a license, and have they heard of this?

Common mistakes when explaining ITSM data

Illustrative scenario

Illustrative: a fictional regional MSP with 90 staff has used one PSA for eight years and an older tool before that. Its owner is planning a PSA migration next year. Because the old system will be retired, the owner asks the SourceX team how history would be handled before the migration, rather than after. Nothing is binding, and the owner decides what the scope would be.

What can a partner do with this?

You introduce; SourceX qualifies, runs the inventory and handles buyer review. You never export or describe tickets.

1. Identify the MSP or IT-heavy company in your network that meets the baseline.
2. Ask one question: how many years of tickets sit in the current system, and who owns the contracts that govern them?
3. Introduce the owner via the referral form or your referral link.
4. Step back while SourceX handles the rest.

Rewards follow the program rules: you earn 25% of eligible platform fees SourceX actually collects, capped at $100,000 per referred company, and only after the buyer pays and SourceX receives its fee. No reward is guaranteed. The AI agents need work data page explains the demand side. Related background: AI agents for ERP and additional revenue streams for MSPs.

Next step

Use the network opportunity finder to list MSPs and IT teams you know, check the who qualifies baseline, and register as a partner to make introductions. MSP-specific context is on the managed service providers page.