Agentic Client Workflows

If you use Claude CoWork, Codex, or another agentic coding environment, you’ve probably noticed that you spend less time inside the applications that actually perform the work. You ask the AI to investigate an alert, retrieve documentation, modify code, or generate a report. The AI decides which systems to consult, which capabilities to invoke, and how to assemble the result. Your work begins in the AI client rather than in the application itself.

That experience depends on something more significant than an API. AI can invoke functions, but performing useful work requires the operational knowledge that determines which functions to invoke, in what order, and under what conditions. Traditionally, that knowledge was embedded within the application itself. A security analyst learned the investigation process by working through the product, gradually acquiring the judgment that connected one action to the next. The interface was not simply presenting capabilities; it was embodying the organization’s expertise.

That separation is beginning to change. Organizations are starting to expose operational knowledge directly through MCP servers and other AI-facing interfaces, allowing AI to consume expertise without reproducing the human experience of navigating the application. Instead of teaching AI how to operate the interface, we can teach it how the work should be performed. The application becomes a provider of trusted capabilities rather than the owner of the workflow.

In our previous article (place here), we introduced the Fluency Logic Layer™ as the architectural foundation for this approach. The Logic Layer separates domain knowledge from presentation, allowing people, AI, and future interfaces to consume the same operational expertise. This article explores why that separation is becoming one of the defining characteristics of enterprise software built for agentic client workflows.

Agentic Workflows Begin in the Client

Claude CoWork, Codex, and similar AI clients are beginning to collect reusable ways of working. A user may start with a prompt that reviews a PDF before it is shared, but the larger pattern is not document review. The pattern is that recurring work is being captured as a reusable skill so the AI can perform it consistently the next time.

That is what we mean by an agentic client workflow. The workflow begins in the AI client, not in the application that eventually performs part of the work. The user defines the intent, the preferred method, and the expected form of the result. The AI client then uses the systems available to it to complete the task.

This matters when the workflow reaches into a product such as Fluency SIEM. A user-defined investigation skill may need Fluency to retrieve evidence, evaluate activity, or explain why an alert matters. At that point, exposing a function is not enough. The function tells the AI what can be called. It does not teach the AI how Fluency expects an investigation to be performed.

That missing instruction is the real gap in many early AI integrations. If a person were learning the system, the organization would provide training. The same principle applies to AI. It needs guidance that explains what the capability means, when it should be used, what assumptions it carries, and how its output should influence the next decision. Without that guidance, the AI is forced to invent the workflow around the function. With it, the AI can apply the product’s operational knowledge inside the user’s agentic workflow.

The MCP Needs to Guide the Workflow

One consequence of agentic client workflows is that they shift responsibility for how work is performed. The user defines part of that process by building reusable skills that reflect personal or organizational preferences. The application has a responsibility as well. It must provide enough operational guidance that the AI can use its capabilities correctly rather than simply invoking them.

The distinction becomes clearer when compared to how people are trained. New employees are rarely handed a list of functions and expected to become productive. They receive examples, guidance, playbooks, and coaching that explain not only what tools are available, but when they should be used, why they are appropriate, and how individual actions contribute to the larger objective. That training represents the organization’s accumulated operational knowledge.

Many early AI integrations stop at exposing functions through APIs or MCP servers and assume the AI will infer the rest. Sometimes it does. Often it invents its own process based on incomplete context, producing inconsistent behavior that is described as hallucination, drift, or poor reasoning. The underlying problem is simpler than any of those labels suggest. The AI was given access to the tools, but it was never taught how experienced practitioners use them.

That missing layer is where headless architectures become interesting. Instead of exposing only capabilities, they can expose the operational knowledge that explains how those capabilities are intended to work together. The AI no longer has to reconstruct years of experience from isolated functions. It can perform the task using the same guidance that would be provided to a newly trained member of the team.

Composing Knowledge

Agentic client workflows combine two different sources of expertise. The user contributes intent, preferences, and the desired outcome. The application contributes the domain knowledge and operational experience that explain how its capabilities should be applied. Neither is sufficient by itself. The user’s skills define the workflow, while the application’s skills ensure that its capabilities participate in that workflow correctly.

This changes the role of the application. Exposing functions allows the AI to invoke capabilities. Exposing operational knowledge allows the AI to understand those capabilities. The distinction matters because an AI that only knows which function to call must invent the process around it. An AI that understands the operational knowledge behind the function can apply the capability as it was intended to be used.

The same relationship extends naturally across multiple applications. A user-defined workflow might combine Fluency’s investigation knowledge with financial information from an accounting platform or customer context from a CRM. The objective is no longer to connect systems. The objective is to compose the expertise each system contributes to the task.

This is where agentic client workflows begin to diverge from traditional integration. Conventional integrations exchange information between applications. Agentic workflows exchange information and combine the operational knowledge that gives that information meaning. As more applications expose reusable skills instead of isolated functions, the value of an agentic workflow will depend less on how many systems it connects and more on how effectively it composes the expertise each system contributes.

So What Does This Mean?

The emergence of agentic client workflows does not make graphical interfaces obsolete. People will continue to use them. What changes is where many workflows begin. Instead of opening an application and learning its interface, users increasingly begin with intent expressed through an AI client, allowing the AI to determine which systems, capabilities, and expertise are needed to produce the result.

That shift changes what software provides. Applications are no longer responsible solely for storing data or exposing functions. They also should expose the operational knowledge that allows AI to use those capabilities correctly. The value of the application becomes less about guiding every user and more about contributing to the user’s workflow.

Agentic client workflows represent an evolution in how people interact with software. The objective is no longer to become proficient with every application that participates in a task. The objective is to achieve the desired outcome. As AI clients become the place where more work begins, enterprise software will increasingly be measured by how effectively it contributes its knowledge to those outcomes, regardless of which interface the user ultimately chooses.