Most workplace technology waits for something to go wrong. Serval’s Catalyst is designed to look for recurring IT work before it becomes a ticket, raising a larger question about whether the future service desk will answer fewer requests because it has quietly removed the need to make them.
An employee cannot access a shared folder. A new hire is waiting for a laptop and the permissions needed to do their job. Someone has forgotten a password, or a device has stopped connecting to the company network. In most organizations, each incident follows a familiar path. An employee submits a request, a service desk receives it, a technician investigates, and a resolution is recorded.
That process is orderly, but it is also reactive. The organization learns about a problem only after a person has spent time experiencing it, describing it and waiting for help.
Serval is trying to move that moment earlier. On August 20, the company announced the general availability of Catalyst, an administrator-facing “super agent” that operates above its AI-native service-management platform. Instead of concentrating only on conversations with employees or support workers, Catalyst is intended to examine the work that repeatedly passes through an IT department and identify opportunities to automate it.
The promise is straightforward: if a service desk sees the same kind of request often enough, the system should not merely become better at answering the request. It should ask whether the request needs to exist at all.
According to VentureBeat, Catalyst can review historical tickets, standard operating procedures and instructions written in natural language. It can identify patterns and draft the components needed to automate them, including workflows, skills, forms, access policies, user journeys and dashboards. Serval is enabling Catalyst by default for customers, a decision that suggests the company regards automation discovery as a central product behavior rather than an optional experiment.
That distinction matters. Enterprise AI has so far been easiest to understand when it behaves like an assistant. A chatbot summarizes a request. A search tool answers a question about company policy. A support agent receives a suggested response. These systems may save time, but they generally remain close to the existing process.
Catalyst points toward a different role. It is not only helping a human carry out the service desk’s work. It is examining the service desk itself and proposing changes to how that work gets done.
The ticket is a record of friction
A ticket is often treated as a unit of work. It is also a record of friction inside an organization.
A password reset may reveal that employees struggle with an authentication system. A recurring request for access to a particular application may indicate that new hires are not receiving the correct permissions during onboarding. A series of device complaints may point to a hardware problem, a confusing setup process or a weakness in the company’s support documentation.
People tend to encounter these issues one at a time. An IT department sees them in aggregate. The difficulty is that finding meaningful patterns in thousands of records requires sustained attention, and service teams are often busy responding to the next urgent request.
This is where an agent such as Catalyst could have practical value. A system that can inspect past tickets and compare them with documented procedures may notice repetition that is obvious in hindsight but difficult for a busy administrator to isolate. It might find that a particular class of employee submits the same access request during the same stage of onboarding. It might identify a process that requires several manual approvals even though the conditions for approval are nearly always the same.
The result would not necessarily be a dramatic replacement of the service desk. It could be a series of smaller changes. A form could gather information that technicians previously had to request by email. A workflow could route a routine request to the correct team. A user journey could guide employees through a standard procedure. A dashboard could expose a growing category of incidents before it becomes a larger operational problem.
These improvements sound modest because most enterprise work is built from modest repetitions. A company does not usually lose productivity through one spectacular IT failure. It loses it through thousands of interruptions that each consume a few minutes from an employee, a technician or a manager.
Automation is most powerful when it addresses those repeated interruptions without demanding that every worker understand how the underlying system works.
From recommendation to action
The important question is not whether Catalyst can generate a workflow. Modern AI systems can produce plausible documents, instructions and process designs. The more consequential question is what happens between a recommendation and a live change.
Serval describes Catalyst as capable of drafting multiple operational components. That wording is significant. Drafting implies that an administrator can review what the system has created before it becomes part of the company’s working environment. But the boundary between a draft and an active process will determine how safe the product is in practice.
An automation that organizes a form or suggests a dashboard is different from one that changes access policies. A workflow that routes a request to a human reviewer carries less risk than one that automatically grants permission to sensitive data. A background agent that identifies a device issue may be useful. An agent that changes a configuration across an entire fleet could create a much wider problem if its assumptions are wrong.
The product therefore needs more than the ability to generate. Administrators need to know why Catalyst identified a pattern, which records influenced its recommendation and what assumptions it made. They need a clear distinction between evidence and inference. A frequent request for access does not necessarily mean that access should become automatic. It could indicate that managers are approving requests too casually, that the organization has poorly designed roles or that a particular application is being used in an unexpected way.
The system also needs a testing stage. Before a new automation reaches every employee, an administrator should be able to run it against sample cases, examine exceptions and see which users or systems would be affected. A process that works for a standard employee may fail for contractors, temporary workers, international teams or people with unusual security requirements.
Approval must be equally explicit. There is a difference between an agent suggesting that a workflow be published and an agent publishing it because it has inferred that publication is the logical next step. The former keeps responsibility visible. The latter risks turning an administrative tool into an unsupervised policy engine.
Finally, organizations need rollback. If a newly generated workflow begins granting the wrong permissions or sends requests to the wrong team, administrators should be able to disable it quickly and restore the previous state. The ability to undo a change is not an afterthought in systems that affect access to tools and information. It is part of the basic design.
The danger of turning repetition into permission
The most tempting assumption in workplace automation is that repetition equals suitability for automation. Often it does. Not always.
A recurring password reset may be a strong candidate for self-service. A recurring request for access to a financial system may require more care. Frequency tells an organization that something is happening repeatedly. It does not explain why.
This is a familiar problem in data-driven management. When a pattern appears in historical records, it can reflect a genuine operational rule, but it can also reflect an old workaround, an inconsistent policy or a bias in who has been able to request help. If an AI agent learns from existing tickets, it may reproduce the habits of the organization that created those tickets.
For example, a team might submit unusually few support requests not because it has fewer problems, but because its employees have learned that asking for help is slow. Another team might generate many requests because it is required to document every small action. A system that treats ticket volume as a direct measure of need could draw the wrong conclusion.
The same issue applies to standard operating procedures. Written procedures may be incomplete, outdated or designed for conditions that no longer exist. Human technicians often compensate for these gaps through experience. An agent reading the documents may not know which unofficial steps are essential and which are merely historical artifacts.
That does not make automation discovery impossible. It means the process must include people who understand the context behind the data. Administrators should be able to challenge the source material and explain exceptions. Employees should have a way to report when an automated process has made their work harder. A successful system will not merely eliminate tickets. It will reveal which processes deserve a closer look.
A service desk with fewer conversations
If Catalyst works as intended, the visible change for employees may be the absence of a conversation.
A new hire could receive the right access through an improved onboarding flow instead of opening several requests. A routine software installation could happen through a guided process. A known device problem could be detected and addressed before a worker loses an afternoon waiting for support. The service desk would still exist, but part of its role would shift from handling individual incidents to designing and supervising the systems that prevent them.
That transition could alter how IT teams measure their performance. Ticket volume has long been an easy metric, even though it can be misleading. A busy service desk is not necessarily an effective one, and a quieter service desk may reflect successful prevention rather than reduced demand.
Organizations may need to pay more attention to time lost by employees, the number of repeated incidents, the quality of onboarding and the frequency of avoidable access problems. They may also need to recognize a new category of work: reviewing automations, monitoring exceptions and checking whether an apparently successful workflow is producing hidden costs.
This could create opportunities for IT professionals whose expertise lies in process design and organizational understanding. It could also create anxiety for workers whose jobs have been built around routine ticket handling. When automation removes repetitive tasks, the benefits are not distributed automatically. Companies must decide whether employees will be trained for more complex work, assigned to oversight and improvement, or simply expected to handle a smaller staff with broader responsibilities.
The human impact will depend on whether organizations treat automation as a way to improve working conditions or primarily as a way to reduce headcount. An employee who no longer spends hours completing repetitive access requests may gain time for security reviews, user education and strategic projects. An IT worker who no longer handles routine tickets may become more valuable if the company invests in the judgment needed to manage automated systems. Without that investment, the same change can feel like a loss of control.
The larger race toward background agents
Catalyst arrives as technology companies compete to make AI agents useful outside the chat window. The basic ambition is to create systems that can observe a changing environment, interpret instructions and carry out multistep work with less constant supervision.
IT service management is an attractive place to pursue that ambition. The environment contains structured records, documented processes, identifiable users and measurable outcomes. Many tasks are repetitive, and organizations already have years of historical data that can help expose patterns.
It is also an unforgiving environment. Permissions are not just administrative details. They determine who can see information, use applications and perform sensitive actions. A mistaken answer in a chat may waste time. A mistaken access rule may expose data or block an employee from doing essential work.
That combination makes IT a useful test of enterprise agents. The products cannot succeed through fluent language alone. They must show restraint, traceability and a reliable understanding of authority. They must know when to proceed, when to ask for clarification and when to leave a decision with a human.
Serval’s decision to enable Catalyst by default makes these questions more immediate. Default availability can help customers discover value without a lengthy implementation process. It can also make the company’s assumptions part of the customer experience before every organization has developed its own governance rules.
Customers will want to understand what enabling the product means in operational terms. Does Catalyst only analyze information, or can it take action? Which data can it inspect? How are sensitive tickets handled? Can administrators limit the systems and teams it can affect? What audit trail records its recommendations and subsequent changes? How are generated workflows evaluated over time?
These are not objections to the idea of proactive automation. They are the conditions that would make it credible.
The future may be measured in avoided work
The most interesting possibility in Serval’s launch is not that an AI agent can write a form or assemble a workflow. It is that the service desk could become a place where organizations study the causes of support work rather than simply process its symptoms.
That would represent a change in the meaning of automation. Instead of adding a digital worker to an existing queue, companies would use AI to search for the conditions that created the queue. The goal would be fewer interruptions, fewer handoffs and fewer moments when an employee must stop productive work to explain a problem that the organization has already seen many times.
But prevention must remain accountable. The absence of a ticket does not prove that a problem has been solved. It may mean the employee found another route, gave up or never realized that a system was restricting their work. An automated process can make a company more efficient, or it can make its decisions less visible.
Catalyst will therefore be judged not only by how many workflows it creates, but by whether administrators can understand and control them. The strongest version of the product would help organizations find patterns while preserving human responsibility for consequential decisions. It would make routine work disappear without making its logic disappear with it.
The service desk of the future may still answer questions. Its deeper achievement could be ensuring that fewer people need to ask them.