Dynamic applications can adapt workflows in real time as tasks change, reducing user navigation and repetitive input and providing agents with structured paths.
Most application workflows are designed in advance. We decide which screen comes first, which fields appear on a form and what happens after someone clicks submit. The path may branch based on role or account state, but the application still follows behavior we programmed in advance.
AI gives us room to adapt a workflow while a task is in progress. For example, a model can interpret what the user is trying to accomplish, retrieval can bring in relevant context and an agent can inspect application state before deciding which action to request. The interface can then surface the information or controls that fit the current task.
This is the idea behind a dynamic application. Parts of a workflow can change based on user context, application state and agent activity, while the application keeps control of permissions, validation and business rules.
From Fixed Workflows to Dynamic Workflows
Consider an expense application. A standard flow might ask a user to upload a receipt, enter the merchant, select a category, choose a cost center and submit the expense for review. Some steps exist because the application needs information it cannot resolve on its own.
With an AI-powered workflow, a model can extract the merchant and total from the receipt. Application code can load the employee’s cost center, while retrieval can find the policy that applies to the expense. If the only missing value is a project code, the interface can ask for that value rather than showing the full form.
We’ll still need the same validated expense record before submission, but the application can adapt how we get there based on the information already available. This separation means we can keep workflow states and business rules in code while allowing the AI layer to help choose the most useful next step.
Context Makes the Experience Adaptive
For an application to adapt effectively, it needs to understand more than the immediate request. It also needs context about the task taking place.
Much of that context already exists in systems we build today. The frontend knows which record is open, which view is active and what the user selected. The backend knows the user’s permissions, account state and related records. Retrieval can add documentation or policy, while application-managed memory can supply preferences that remain useful across sessions.
Take a support engineer opening a billing case. The application already knows the customer, the disputed invoice, and the engineer’s permissions. An agent can inspect recent payments and retrieve the refund policy. Instead of opening several tabs and gathering the same information by hand, the engineer can start with the invoice mismatch and the relevant policy in view.
It’s important to keep in mind that we should still limit the context passed to the model. Sending an entire customer record adds token cost and may expose fields the current task does not need. The backend should assemble the smallest useful context for the request, just as it filters data for any other application feature.
The same principle applies to tools. A billing agent may need get_payment_history and get_refund_policy, but it doesn’t need access to every operation in the support system. Context and capabilities should always match the task.
Adapting the Interface Without Generating the Whole UI
When building dynamic applications, we’ll generally want to avoid generating the whole UI dynamically because that makes the experience harder to predict, test, and maintain. Instead, we can keep the interface grounded in components we already control, then use context to decide which component should appear for the current task and workflow state.
Suppose a support application has three contextual panels:
If an agent finds a duplicate charge, the backend can return an invoice_comparison panel. The frontend then maps that panel type to the corresponding component. If the workflow later requires approval, the backend can return refund_approval, and the same region updates to show the approval interface. The frontend still owns the layout, accessibility behavior, loading states, and controls for each component.
This pattern gives us a useful form of personalization as well. Two people can open the same record and need different information because they have different responsibilities. A support engineer may need the conversation history and refund controls, while a billing specialist may need payment history and policy details.
When an Agent Changes the Workflow
So far, we’ve looked at how the interface of a dynamic application can adapt based on context. The same idea extends to workflows where an agent is actively completing work on the user’s behalf. An agent can receive a goal, choose tools and progress through several steps, with each step potentially changing application state while the user remains on the same screen.
Imagine an agent helping with the billing case example we’ve discussed above. It reads the payment history, retrieves the refund policy and confirms that the customer was charged twice.
If the amount falls within its delegated limit, the agent may prepare a refund. If the amount requires approval, the workflow should pause and surface that decision in the interface.
A chat transcript can describe what the agent is doing, but the application already has a better place for most of this information. The invoice view can mark the duplicate payments, the approval can appear beside the refund amount, and the activity history can record what the agent checked and what action it requested.
This gives us several interface states to design for:
- Working: Show which record or step the agent is processing.
- Awaiting approval: Show the proposed action and the evidence behind it.
- Completed: Update the affected record and preserve a summary of the change.
- Escalated: Make clear that the agent stopped and show what needs human attention.
These states connect the agent to the workflow instead of placing its work inside a separate assistant panel.
Keep Authority in the Application
Dynamic workflows still need fixed boundaries. The interface may adapt, and the agent may choose its route, but application code should enforce permissions, policy and valid state transitions.
Let’s consider a refund request. The model may prepare the amount and reason, but the backend can route that request according to business policy:
With the above, the interface can render a different state for each outcome. A small refund can proceed, a larger one can pause for approval, and a request outside policy can move to a human owner.
The model does not decide how much authority it has since execution limits need to be predictable and enforceable. Tool permissions, schema validation and policy checks enforce that boundary outside the model.
One Dynamic Workflow End to End
We can bring the pieces together with the refund example we’ve discussed in this article. To start, assume a support engineer opens a billing case and asks:
Can we refund this charge?
Can we refund this charge?
A dynamic application can handle the request as follows:
- The backend receives the question with the current customer, billing case and user permissions.
- The agent loads the relevant invoice, payment history, conversation details and existing refund requests.
- It retrieves the applicable refund policy and checks for conditions such as duplicate charges, prior refunds, payment status and refund limits.
- The case view highlights the disputed payment, shows the evidence supporting the request and displays the policy conditions that apply.
- The workflow surfaces related information, such as previous refunds, unresolved disputes or a mismatch between the invoice and payment records.
- The support engineer asks a follow-up question, adjusts the proposed amount or selects the refund request for more detail.
- The backend validates access to the selected records and retrieves the latest payment and case state before preparing or executing the request.
- If approval is required, the interface presents the proposed refund, amount, evidence and policy basis for review.
- The refund remains subject to the application’s authorization, validation and policy checks, while the activity history records the questions asked, evidence reviewed and action taken.
The interface adapted during the conversation, but the billing case remained the same product surface. The agent gathered context through structured tools and presented explanations alongside the records the support engineer was reviewing. The user received a task-specific view without having to navigate through several support screens.
This is the useful middle ground for dynamic applications. We can make workflows responsive to intent and context without making the application itself unpredictable.
Wrap-up
Dynamic applications can adapt parts of a workflow as the task changes. The application can use current UI state, account data, retrieved knowledge and agent activity to decide what information and controls belong in front of the user.
For users, this can reduce navigation and repeated data entry. For agents, it creates structured paths into the same capabilities that power the interface. Both consumers work against the same backend rules for permissions, validation and execution.
As applications serve both people and agents, this balance is important. The workflow can adapt in real time, while the application remains responsible for what each participant can see, change and approve.
For more on building AI-powered applications and agents with Progress, check out the following resources:
- Progress Agent Engineering Solutions
- Progress Agentic RAG
