Agents are providing an astronomical amount of value for organizations, and they're here to stay. But I want to make this point very clear. They are not set and forget by any means. To get the most out of them, observability is just as important as initial design and implementation.

While agents are replacing manual human tasks, humans are still required for agentic operations. Roles such as agent operators, architects, and analysts are essential to maximizing value and operational benefits. Agent operators are the ones who not only understand the tech but also understand the business inside and out. They continuously observe, audit, fine-tune, and optimize agents. And with the introduction of agentic agents into the workforce, these people can now take on more of a strategic role within the organization.

With the shift of moving manual tasks towards agentic agents, it can be a little daunting on where and how to start. I've been working with a lot of customers on getting started with agents within Nintex, and when it's uncharted territory, that initial "this is too complex" feeling is completely normal. But after the learning curve, I see customers experimenting, building, and deploying to production within weeks.

You will see there is a ton of available configuration within the agent action, and it's not there to scare you. It's there to help you configure what you need so you achieve 95%+ accuracy, which is the typical benchmark for success.

So let's go through what a typical agent configuration consists of. In this example we will be using Nintex agents, but the industry concepts typically stay the same across platforms.

And it's worth mentioning, learning what processes are best suited for agents is obviously important, but you'll be surprised. With new models being released, the more capable they are at handling increasingly complex work. The scope of use cases is growing by the week. You can calculate true ROI with agents, so be sure to check out my ROI calculator, which is based exactly on this.

When you're just trying things out, start with a single agent. Keep it simple, learn how the configuration works, and get comfortable with the results. But when you're moving into POC territory and the use case gets more complex, I'd recommend using the Agent Advisor to get a solid starting point. It will help you determine if you need a multi-agent approach and which models are best suited for each part of the use case. Typically we want agents to handle specific sections of the work, things like analysis, classification, reasoning, and so on, rather than trying to do everything in a single prompt. Breaking the work into focused agents gives you better accuracy and more control over each step.

It's also best practice to retrieve a confidence score from your agents. This is how you build a reliable human-in-the-loop fallback. If an agent returns a confidence score below a certain threshold, the workflow can route that task to a human instead of acting on a low-confidence decision. This is critical for production use cases. It means the agent handles the work it's confident about autonomously, and anything it's unsure of gets escalated. You get the speed and cost benefits of automation while still maintaining quality and accountability. Over time, as you fine-tune your agents and observe what's driving low confidence scores, you can adjust your prompts, models, and knowledge sources to push that threshold higher and reduce the volume of human intervention needed.

Reasoning Effort

This controls how much thinking the model does before responding. It's only applicable to reasoning models like o1 and o3. Set it to Low for simple, straightforward tasks where speed matters. Medium is a good default for most use cases. High is for complex tasks that need deeper analysis, like multi-step decision making or working through nuanced data. If your agent is doing basic classification or routing, keep it low. If it's reviewing contracts or analyzing financials, crank it up.

Temperature

Temperature controls how creative or predictable the model's responses are. A low temperature (like 0.1) means the model will be very consistent and deterministic, giving you the same answer almost every time. A high temperature (like 0.8 or above) introduces more variation and creativity. For agents doing structured work like data extraction, compliance checks, or approval decisions, keep the temperature low. You want reliability, not creativity. If you're using an agent for content generation, feel free to push it higher.

Agent Role and Rules

This is where you define who the agent is and how it should behave. Think of it like onboarding a new employee. You're telling the agent what its job is, what it should and shouldn't do, and how it should respond. The more specific you are here, the better the results. This is where you set the guardrails. You can define things like the tone of the response, the format you want back (like JSON or plain text), what the agent should do when data is missing, and any business rules it needs to follow. A well-written role and rules section is the difference between an agent that gives you useful, consistent output and one that goes off track.

Work Request

This is the actual task you're handing to the agent. If the role and rules define who the agent is, the work request defines what you need it to do right now. This is where you pass in the dynamic data from your workflow and tell the agent exactly what to do with it. For example, "review this invoice," "classify this support ticket," or "summarize this document." Keep it clear and direct. The work request is what gets executed every time the workflow runs, so it should be written in a way that works consistently across different inputs.

Why does this matter?

Separating the role from the request is what makes agents reusable and reliable. The role and rules stay the same across every execution. The work request changes based on the data flowing through the workflow. This separation means you can fine-tune the agent's behavior once and then trust it to handle whatever gets thrown at it. It's the same principle as giving a team member a job description and then assigning them individual tasks. The job description doesn't change every day, but the tasks do.

An example Agent Role and Rules could be:

You are a procurement review agent. Your role is to analyze purchase requisitions and determine if they meet company policy. You must check that the requested amount is within the submitters approval threshold, that the vendor is on the approved vendor list, and that the cost center is valid. 
If all criteria are met, respond with APPROVED and a brief summary. If any criteria fail, respond with REJECTED and list the specific reasons. Always respond in structured JSON format. Do not make assumptions. 
If data is missing, flag it as INCOMPLETE and specify what is needed. You must also return a confidence score between 0 and 100 representing how confident you are in your decision. If you are uncertain about any aspect of the review, reflect that in the score. A score below 70 should indicate the decision needs human review."."

An example Work Request could be

Review the following purchase requisition and determine if it should be approved, rejected, or flagged as 
incomplete based on the company policy rules defined above. 
Return your decision, reasoning, confidence score, and any flags. Here is the requisition data: {{PurchaseRequisition}}

Tools

This is where you give your agent the ability to actually do things beyond just thinking and responding. By default, an agent can only process text. But when you add tools, you're giving it hands. It can now reach out and interact with external systems as part of its work.

In this example, we've added Google Docs as a tool. This means the agent can read from or write to Google Docs as part of its task. So if your work request asks the agent to generate a summary and save it somewhere, the agent can now do that autonomously without needing a separate workflow action to handle it.

You can add multiple tools by clicking "Add tool," and the agent will decide when and how to use them based on the work request and the role you've defined. This is where agents start to feel fundamentally different from a standard AI prompt action. They're not just giving you an answer. They're taking action on it.

When to use tools

If your agent only needs to analyze data and return a response, you don't need tools. Keep it simple. But if you need the agent to interact with systems like creating a document, updating a record, sending a message, or pulling in external data as part of its reasoning, that's when tools come in. Think of it this way: the model tab is the brain, and the tools tab is what lets the agent act on what it's thinking.

Knowledge

This is where you give your agent access to reference material so it can make informed decisions based on your organization's data. Without knowledge, the agent only knows what you tell it in the prompt. With knowledge, it can look things up on its own.

Shared Context

This setting lets the agent access outputs from earlier agents in the flow. So if you have multiple agents in an orchestration and Agent 1 has already done some analysis, Agent 2 can pick up that context and build on it rather than starting from scratch. It's worth noting that enabling this increases token usage, so only turn it on when agents genuinely need to be aware of what happened before them in the flow.

Document Store

This is where you connect your agent to a Nintex Document Store. Think of it as giving the agent a filing cabinet it can search through. If your agent needs to reference company policies, SOPs, contracts, or any other documents to do its job properly, this is where you point it.

The "Describe Knowledge" field is important. This tells the agent what's in the document store and when to use it. Be specific here. For example, instead of just saying "company documents," say something like "This contains the company's procurement policies including approval thresholds, approved vendor lists, and expense category guidelines." The better you describe it, the better the agent knows when and how to search for the right information.

Return Source Documents lets you choose whether the agent includes references to the specific documents it pulled from. This is useful for traceability and auditing, so you can see exactly what the agent based its decision on.

Vector Embedding

This is the more advanced option for knowledge. Instead of a Document Store, you can connect directly to a Vector Store with embeddings. This is for scenarios where you've already set up a vector database and want the agent to perform semantic search against it. You provide the vector store, the embedding model, a knowledge name and description, and the agent will use that to find the most relevant content when processing its work request.

For most use cases, the Document Store option will get you where you need to go. Vector embeddings are for when you need more control over how the knowledge is stored and searched, or when you're working with larger volumes of data where semantic search gives you better results.

Output

This is where you define how the agent returns its response. The output format you choose here determines how you can use the agent's response in the rest of your workflow, so it's an important decision.

Return Response As

You have two options here: Structured Output and User Message. They serve very different purposes.

Structured Output

This is the option you want when the agent's response needs to drive your workflow logic. You define a JSON schema with keys, data types, descriptions, and whether each field is required. The agent then returns its response in that exact structure, every single time.

For example, if your agent is reviewing purchase requisitions, you might define keys like "decision" (string), "reason" (string), "amount" (number), and "flagged" (boolean). Because the output is structured, you can map each key directly to workflow variables. That means you can use the agent's decision in conditions, route the workflow based on what the agent returned, update records with the results, or pass specific values to the next agent in the orchestration.

This is what makes agents genuinely useful in automated workflows. You're not getting back a block of text you need to figure out how to parse. You're getting clean, predictable data that you can wire up just like any other variable in your workflow. Define the schema once, and every time the agent runs, the output slots straight into your logic.

The "Manual edit mode" toggle lets you switch to editing the JSON schema directly if you prefer that over the form-based builder.

User Message

This is designed for when the agent is generating content that a person will read. Things like writing a summary of a document, drafting an email to send, composing a response to a support ticket, or putting together a report. The agent returns its response as plain text, and you map it to a workflow variable.

You're not trying to extract individual data points here. You're using the agent to produce written content that gets delivered to someone or stored somewhere as is. If you're sending the output into an email action or displaying it to a user in a form, User Message is the right choice.

Which one should you use?

If the agent's response needs to feed into downstream workflow logic, conditions, routing, or other systems, use Structured Output. If the agent is producing content for a human to consume, use User Message. Think of it this way: Structured Output is for the workflow to act on, User Message is for people to read.

Output Variable

At the bottom you'll see the Output field where you select a variable to store the agent's response. This is where the result lands so the rest of your workflow can use it. For structured output, this will contain the full JSON object with each key available as a workflow variable. For user message, it will contain the text response as a single value.

As I mentioned at the start, agents are not set and forget. The configuration we've walked through here is what gets you up and running, but the real value comes from what happens after deployment. Monitoring, fine-tuning, and continuously improving your agents is what separates a proof of concept from a production-grade solution.This is where agent operators come in. They're observing how agents perform in the real world, identifying where accuracy can be improved, adjusting prompts and parameters, and making sure the agents are delivering on the business outcomes they were designed for. It's an ongoing practice, not a one-time setup.The good news is that once you get past the initial learning curve, the speed at which you can iterate is incredible. Adjusting a prompt, swapping a model, tweaking the temperature, adding a knowledge source. These are minutes of work, not weeks. And the impact on accuracy and output quality can be massive.If you're just getting started, don't overthink it. Pick a process, configure your agent, test it, and learn from the results. The more you experiment, the faster you'll understand what works and where agents can deliver the most value for your organization.

Comments

Comments