How to build Enterprise-aware agents

Should an AI system follow a predefined business process, or decide for itself how to accomplish a task? That is the opening problem in Chau Tran’s account of enterprise-aware agents: bringing model capabilities into the messy reality of how a business operates.

A workflow orchestrates LLMs and tools through predefined code paths. There are two common ways to express those paths:

• Imperative code: A program calls the LLM, reads its response and invokes tools. The programmer directly controls execution.
• Declarative graphs: Nodes represent steps such as model calls or tool calls, and edges connect them. The graph specifies the structure; a workflow framework handles execution.

Both provide structure and relative predictability. Running the workflow again should mostly follow the same process, even though individual model responses may vary.

An agent lets the LLM dynamically direct the process. Given a goal, it decides which steps to take and which tools to call. Its core loop is simple:

1. Receive a task or goal from a person.
2. Plan the next step.
3. Execute an action.
4. Observe the result from the environment.
5. Repeat until it has the results it needs, then respond.

The difference is who determines the path: the developer in a workflow, or the model during an agent’s execution.

Tran compares workflows to a Toyota: predictable and useful for repetitive tasks or established business practices. They generally cost less and respond faster because the model does not need to make a planning call at every decision. Explicit code or graph steps also give developers somewhere to locate a failure. Humans can adjust the process to make a task work with an imperfect model.

Agents are his Tesla: more open-ended, capable of tackling unsolved research problems and benefiting from stronger models without requiring every new behavior to be programmed. Their simple core loop means less application logic to maintain, but dynamic planning generally adds cost and latency. They can also take an unexpected wrong turn—the moment when predictable execution becomes attractive again. These are architectural tendencies, not measured performance results.

The boundary changes with model capability. A task that fails in an agent loop today may become practical with a later model. That makes a permanent choice between workflows and agents difficult—and raises a more useful question: can the two improve each other?

Give an agent a task and it chooses an action, observes the result, then chooses another action. Once execution finishes, its trace contains a sequence of steps. That completed sequence is a workflow. Viewed this way, an agent takes a task and generates a workflow for accomplishing it, discovering the path as it goes.

This makes a library of golden workflows useful for evaluation. Each example pairs a task with the steps the company considers appropriate for solving it. Run the agent on that task, inspect what it actually did and compare its steps with the reference procedure. The evaluation asks whether the agent followed the right process, rather than judging only whether its final response looks convincing.

The same library can teach the agent. For known tasks, the aim is to reproduce established procedures. For new tasks, the model can use its reasoning to combine workflows or extend what it has learned. The library supplies company know-how; the agent supplies a way to apply that know-how beyond the original examples.

The relationship also works in the other direction: an agent can help build workflows. In Tran’s description of Glean Agents, a user describes a task in natural language. An agent figures out the necessary steps and proposes a workflow in the builder. The user can then edit those steps. Generating a proposal and accepting it as the desired procedure are separate actions.

A broader possibility is to use agents as a workflow discovery engine:

1. Ship an agent that lets users attempt new tasks.
2. Let users identify executions that accomplished those tasks well.
3. Save the successful workflows as examples of how to do the work in that company.
4. Accumulate those examples as training data to improve the agent.

Tran presents this as a way to turn successful use into reusable organizational knowledge, not as evidence that every shipped agent automatically captures and retrains on its runs.

Would these procedures still matter if models reached AGI? Tran’s thought experiment treats AGI as a highly intelligent new employee. Intelligence alone does not tell that employee how the company operates, whom to contact when blocked or which nuanced practices govern a task. Enterprise awareness means being fully onboarded into those ways of working.

Competitor analysis makes the distinction concrete. An agent can search Google, read outside material and produce an acceptable report. A great report must also follow the company’s protocols and address the metrics its executives care about. A plausible answer is not necessarily the answer the organization needs. The workflow library captures some of the process knowledge that separates the two.

Once task–workflow examples exist, how should they change agent behavior? Tran describes two approaches his team has experimented with. The first is fine-tuning, with two forms of supervision:

• Supervised fine-tuning: Supply an input and an expected output, then train the model to imitate that behavior.
• RLHF: In Tran’s description, supply a rating or reward indicating whether a workflow is good, rather than a golden output, and optimize the model using that feedback.

With enough task and workflow data, fine-tuning can support generalization across tasks and the combination of different workflows.

The maintenance cost is that the adapted model becomes a fork of its base model. A stronger frontier model may arrive by the time tuning finishes, creating pressure to repeat the process. Changes to the training examples also require another adaptation cycle: a new tool can make an old workflow obsolete, and new business priorities or processes can change what the correct workflow should be.

Personalization adds another difficulty. Two teams—or two employees—may need different procedures for the same task. A single learned behavior is less flexible when the optimal workflow depends on who is asking.

The second approach is dynamic prompting through search. Keep the task–workflow pairs in a searchable library. When a new request arrives, find similar tasks and put their workflow representations into the LLM’s prompt as examples. The knowledge is supplied at runtime instead of being incorporated into model weights.

This creates a spectrum between familiar procedures and model creativity. If no workflow matches the task, the model has more room to devise a new one. If retrieval finds a high-confidence match, the examples encourage the model to produce a similar workflow. This is guidance through prompting, not a guarantee of deterministic execution.

Return to competitor analysis, this time with the request: what competitors have we been running into recently? The library can supply a procedure for analyzing a competitor and another for finding recent customer calls. The model uses these examples to compose a proposed workflow:

1. Read recent customer calls.
2. Read internal messages.
3. Extract the competitors mentioned.
4. Run an analysis for each competitor.

The task requires more than copying one retrieved procedure. It connects discovery of recent competitive encounters with an existing method for analyzing each competitor. The example illustrates the generated process; it does not report results from executing it.

Fine-tuning and retrieval solve different adaptation problems. Tran favors fine-tuning for generalizing from substantial data and dynamic prompting for flexibility. Retrieval also makes the examples influencing an output available for inspection.

The distinction matters most in the last gap between broadly competent behavior and the specific process a team needs.

Tran’s analogy is custom hardware versus software. Fine-tuning resembles building specialized hardware for a well-understood task whose requirements stay stable: specialization can be valuable, but changing the requirements is costly. Dynamic prompting resembles software: it may not offer the same degree of specialization, but its instructions and examples can change quickly.

Workflow search begins much like document search: compare a new task with task descriptions in the library. Tran names hybrid lexical and vector search, reranking and late interaction as techniques for textual matching. Together, these address the first question: which stored tasks resemble this request?

Enterprise search has a second question: which of the plausible matches should this person use? Once users can create their own documents and workflows, a library may contain hundreds or thousands of similar-looking entries. That is Tran’s illustration of the selection problem, rather than a measured corpus size. Textual similarity alone cannot resolve it.

Authoritativeness adds organizational context to relevance. Tran proposes using knowledge-graph relationships and signals such as whether a workflow’s creator works closely with the requester, whether the workflow has a strong record of success and whether people discuss it on Slack. Recommender-system techniques can help select among these candidates.

These signals are difficult to encode directly into an LLM. That motivates a separate workflow-search system: it can account for relationships and evidence of usefulness when choosing the examples the model receives. Enterprise awareness therefore depends on retrieving the appropriate procedure for the user, not merely finding one whose description sounds similar.

The closing question asks whether RLVR could reduce the amount of data needed for fine-tuning, suggesting a reward model as the source of feedback. There is a terminology distinction here: in the original Tülu 3 formulation, reinforcement learning with verifiable rewards uses a verification function rather than a learned reward model. It still needs suitable tasks and outcomes that can be checked.

Tran reframes the question as how much fine-tuning data is needed with RLVR. His answer is conditional: it depends on how far the task falls outside the distribution of the model’s existing knowledge. He gives no numerical threshold or demonstrated reduction in enterprise training-data needs, leaving that question for further discussion.