AI agents in workflow automation are built to get work done, not just have conversations.
With PDIQ, a published agent can be used in chat or added as a step inside a workflow. Within a workflow, it receives information from previous steps, handles the part that requires interpretation, and returns structured output that subsequent steps can use.
In the previous post in this series, we explored the data, retrieval, and agent layers beneath PDIQ. This post moves up the stack to show how an agent becomes part of an operating process: how it is built, connected to business systems, activated, monitored, and governed.
Build the agent for one job
The process begins in Agent Builder, MyPDI’s no-code workspace for creating and testing agents. A creator defines the agent’s purpose, the information it can use, and the tools it can call. Depending on the task, that can include:
- Knowledge Base content such as policies, contracts, and tenant-specific documents
- Web Search when current external information is required
- Approved tools and connections that provide data or perform a specific action
- Other focused agents when several types of reasoning are needed within a Chain of Agents
The narrower the assignment, the easier the agent is to evaluate and govern. An agent designed to classify an invoice exception has a clearer success condition than one expected to manage an entire accounts payable process.
Before publication, the agent can be tested against representative inputs in Agent Builder. Once published, it becomes a reusable asset. A user can call it in PDIQ Chat, or a creator can add it as a step in a workflow.
Place judgment inside a predictable workflow
A workflow agent does not need to control the whole process. It is most useful when it owns the step that requires interpretation while ordinary workflow components handle predictable work.
Consider invoice exceptions in a fuel or convenience retail back office. A workflow could follow this sequence:
- A scheduled trigger checks for open exceptions.
- The workflow retrieves the current batch from a connected system.
- Deterministic steps extract and prepare the relevant records.
- An agent identifies the document type, vendor, amount, and exception, then recommends a resolution with supporting reasoning.
- The workflow branches on fields such as exception type, amount, or confidence level and either continues automatically or sends the case for review.
This division of labor keeps the process observable. Code can handle arithmetic and exact comparisons. Connectors can move records and files. The agent handles variable inputs, such as inconsistent vendor names or a purchase order number placed in an unexpected field. Each step has a specific job, so teams can identify where a run failed and correct that part of the process.
The agent’s response is treated as data rather than a final answer for a person to read. It might return a document classification, vendor match, variance amount, risk flag, and confidence score. The next step can use those fields to file a clean invoice, request more information, or route an exception for review. Natural-language judgment becomes an input to a controlled business process.
Connect the workflow to business systems
Workflow Builder brings together triggers, data transformations, connectors, notifications, approvals, and agent calls on one canvas. Connections allow the workflow to retrieve information from or send actions to approved systems, including enterprise applications, collaboration tools, file services, and PDI data sources.
The workflow structure remains consistent even when the connected systems change. A connector might retrieve an invoice from a mailbox, check a record in an ERP, write the result to a file or database, or notify a team when a decision requires attention. The agent operates within that larger sequence instead of acting as a separate destination.
Activate and monitor each run
Workflows remain inactive until a user deliberately turns them on. After activation, a workflow can begin through several trigger types:
- A schedule starts it on a recurring cadence.
- A webhook allows another system to start it when an event occurs.
- A supported application event starts it when a new email, row, or record appears.
- A manual trigger supports testing and intentionally initiated processes.
Scheduled and event-driven triggers allow work to continue without someone remaining logged in or selecting Run. Autonomous execution still needs operational visibility, however. Each run records its trigger and status, along with details about the steps that completed or failed. A team can open the run history, locate the affected step, and diagnose the input or connection that caused a problem.
Pause when a person should decide
Human oversight is also part of the workflow design. When a run reaches a decision that requires authority or context beyond the agent’s role, an approval step can pause the workflow and send the request to the appropriate person. The reviewer receives the relevant document and the agent’s reasoning, makes a decision, and the workflow resumes along the corresponding branch.
The strongest designs use this pattern for exceptions rather than every transaction. In the invoice example, cases that meet agreed rules and confidence thresholds can continue automatically. A high-value variance, a vendor with no reliable match, or a low-confidence interpretation can be routed to a person.
This keeps human attention focused on the decisions where judgment and accountability matter most. It also prevents an automated process from simply creating a new approval queue for every item it handles.
Apply governance to every connection and action
A workflow may interact with an ERP, mailbox, CRM, or file server, so its access cannot depend on credentials placed directly on the canvas. PDIQ applies several controls across the process:
- Registered connections keep credentials encrypted and managed separately from the workflow.
- Role-based access control determines who can build, test, publish, activate, or administer assets within a tenant.
- Tenant boundaries limit which data and assets a workflow can access.
- Audit records capture meaningful events such as workflow activation, connection changes, role assignments, and approval decisions.
These controls make unattended execution manageable. A creator can use an approved connection without seeing the underlying secret, while administrators retain control of credentials and permissions. Teams can also see which connection a workflow used, who changed its configuration, why a run paused, and where a failure occurred.
Autonomy remains bounded by the same identity, access, and accountability requirements that apply elsewhere in the platform.
From an agent to an operating process
A deployed agent is one component in a larger system. It is built for a defined job, grounded in approved information, tested against representative inputs, and inserted only where the workflow needs judgment. Triggers start the process, deterministic steps handle predictable work, connections reach approved systems, and human approvals govern the decisions that should not proceed automatically.
That structure allows an agent to move beyond conversation and support daily operations. The model does not own the process. It contributes a specific capability inside a workflow that remains observable, governed, and accountable from beginning to end.
In the next post, we will examine how proven agents and workflows can be shared and reused across a business through the Marketplace.