Agentic AI refers to AI systems that pursue a goal by planning steps, using tools and checking their own progress, rather than just answering a single prompt. For business, AI agents are useful today for bounded, well-instrumented tasks such as triaging requests, researching across documents, extracting and reconciling data and drafting work for human approval. They still fail at long, open-ended tasks with vague success criteria. This guide explains how agents work, where they fit, and what good agentic AI consulting should put in place before an agent touches your systems.
What an AI agent actually is
Strip away the marketing and an agent has four parts. Understanding them makes it much easier to judge a vendor pitch or scope a project.
- A model. A large language model does the reasoning: reading the request, deciding what to do next and writing the output. It can be a hosted commercial model or an open-weight model such as Qwen or Llama running on your own infrastructure.
- Tools. Functions the model is allowed to call: search a document store, query a database, look up a customer, create a ticket, send a draft for approval. Tools are what let an agent act on the world rather than just talk about it. The Model Context Protocol (MCP) has become a common way to expose tools and data sources to agents in a consistent format.
- Memory. The working state of the task (what has been tried, what was found) plus, where useful, longer-term context such as user preferences or past cases. Memory is usually just structured data the system stores and feeds back to the model, not something mysterious inside it.
- A planning loop. The control logic that runs plan, act, observe, repeat. The agent chooses a step, calls a tool, reads the result, and decides whether to continue, change approach, stop or escalate to a person.
The loop is what makes it "agentic." A single call to a model is a function. A model that can decide to search again because the first results were thin, or to stop and ask for a missing purchase order number, is an agent.
Where agents work well today
Agents succeed when the task is bounded, the tools are reliable, and success can be checked. Typical good fits include:
- Research across documents. An agent that plans several searches over a document collection, reads the relevant passages and writes an answer with citations to the source pages. This is the pattern behind our own product, Akurion.ai.
- Triage and routing. Reading incoming emails, tickets or forms, classifying them, pulling relevant account context and routing to the right queue with a draft reply.
- Data extraction and reconciliation. Pulling fields from invoices or contracts, comparing them with records in another system and flagging mismatches.
- Structured research over public data. Gathering and summarizing filings, disclosures or registry records on a schedule. Our product The Filing Fool, which brings SEC filings, insider trades, 13F holdings and congressional trades onto one per-ticker timeline, is an example of structuring this kind of data so it can be reasoned over.
- Drafting for approval. Producing a first version of a report, a response or a summary that a person reviews and sends.
Where agents still fail
Being clear about failure modes is the most useful thing a business leader can know about agents.
- Long, open-ended tasks. Errors compound over many steps. An agent asked to "improve our marketing" will wander; one asked to "summarize last month's support tickets by product and flag recurring complaints" will not.
- Vague success criteria. If a person cannot say whether the output is right, neither can the agent, and neither can your evaluation.
- Unreliable tools. An agent is only as good as the systems it calls. Slow APIs, inconsistent data and missing permissions cause more failures than the model does.
- Confident errors. Models can state wrong things fluently. Without citations, validation checks or review, those errors pass straight through.
- Untrusted input. Text an agent reads, such as an email or a web page, can contain instructions designed to hijack it (prompt injection). Agents that read external content and also hold powerful permissions are a real security risk.
Guardrails that matter
Guardrails are the engineering around the model that keeps an agent inside its lane. The essentials are not exotic.
| Guardrail | What it does |
|---|---|
| Least-privilege tools | Each tool does one narrow thing with the minimum permissions. Read-only wherever possible. |
| Approval gates | Actions that move money, change records or send external messages wait for a person to approve. |
| Input and output validation | Check that extracted values are well-formed and consistent, and block outputs that break policy. |
| Step and cost budgets | Cap the number of loop iterations, tool calls and spend per task so a confused agent stops rather than spins. |
| Separation of untrusted content | Treat text from emails, documents and the web as data, never as instructions, and limit what an agent can do after reading it. |
| Full logging | Record every prompt, tool call, result and decision so you can audit and debug. |
Approvals: start strict, loosen with evidence
A practical pattern is to begin with every consequential action requiring approval, then review the logs. When a category of action has been approved without changes consistently over a meaningful sample, consider letting it run automatically while keeping spot checks. Keep irreversible or high-impact actions behind approval permanently. This turns the question "do we trust the agent?" into something you can answer with your own data.
How to evaluate an agent
Demos are not evaluation. An agent that works on five hand-picked examples can fail on the sixth. Treat evaluation as a standing asset, not a one-off test.
- Build a task set. Collect realistic tasks with known correct outcomes, including the awkward cases: missing information, conflicting documents, requests that should be refused.
- Score more than the final answer. Did it complete the task? Was each tool call correct and permitted? Did it escalate when it should have? How many steps and how much cost did it take?
- Run repeatedly. Models are not fully deterministic, so run each task several times and look at consistency, not a single pass.
- Regression-test every change. Re-run the full set whenever you change the model, prompt, tools or data. Small prompt edits can break cases that used to work.
- Monitor in production. Sample live tasks for human review and feed the failures back into the task set.
Examples by department
The examples below are illustrative patterns, not promises. Each one works best when scoped narrowly and paired with review.
- Finance: extracting invoice data, matching it against purchase orders and receipts, and queuing exceptions for an accounts payable clerk.
- Operations: reading supplier emails for delivery changes and updating a schedule draft for a coordinator to confirm.
- Customer support: classifying tickets, pulling order history and drafting a reply grounded in the help centre and policy documents.
- Sales: researching an account from public sources and internal notes before a call, with citations for every claim.
- HR: answering employee policy questions from the handbook with links to the exact section, and escalating anything personal to a person.
- Compliance: screening names against sanctions lists, resolving likely matches across spelling variants, and preparing a case file for an analyst to decide.
- Legal: comparing a contract against a standard template and listing deviations with page references for a lawyer to review.
One agent or many?
Vendors increasingly pitch "multi-agent" systems, where several specialized agents hand work to each other. This can be useful when tasks genuinely separate into distinct roles with different tools and permissions, for example a research agent with read-only access and a separate drafting step whose output goes to a person. But every handoff is another place for errors to creep in, and debugging a conversation between agents is harder than debugging one. A good rule is to start with a single agent and a small set of well-designed tools, and split it only when evaluation shows a clear reason to.
Agents versus fixed workflows
Not every problem needs an agent. If the steps are always the same (extract these fields, validate them, write them to this system), a fixed workflow that calls a model at specific steps is cheaper, faster and easier to test. Reserve the planning loop for tasks where the right next step genuinely depends on what the previous step found. Many successful "agent" projects are mostly workflow with a small agentic component where the variation lives.
Getting started without over-committing
Pick one task from the list above that is frequent, bounded and checkable. Write down what a correct outcome looks like. Build the evaluation set before the agent. Run a prototype in shadow mode, where it produces outputs alongside staff without acting. Only then connect it to live systems, with approvals on. This sequence keeps costs contained and gives you evidence at each step. If the task involves sensitive data, decide early whether inference must stay in Canada or on your own hardware; a private LLM using open-weight models is often the simplest answer.
How Dassjay Labs helps
Dassjay Labs is a Kitchener, Ontario AI consultancy and product studio serving clients across Canada. Our AI agent development work covers use-case selection, tool and permission design, evaluation sets, approval workflows and production monitoring. We build agents with the same planning, retrieval and citation techniques we use in our own products. If you are weighing where agents fit in your organization, talk to us about a scoped first project.