Building AI Agents for Business: A Cross-Discipline Guide
UIT, UIB Cross-institute lecture
Series Cross-Institute Series | Level Basic (Free)
Duration 15 to 20 minutes | Access Free
Delivering institutes: UIT (Institute of Technology); UIB (Institute of Business)
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to prepare your brain. Play the isochronous tone track (40Hz gamma frequency) with your eyes closed. Gamma-frequency tones before a learning session raise attention and make the material easier to absorb.
[Audio player: UNOP Pre-Lecture Isochrone (40Hz, 5 minutes)]
In this Lecture
The Hook: The Automation That Answered the Wrong Question
A company builds its first AI agent in a week. The engineering works. The agent reads incoming customer emails, classifies them, and drafts replies. The demo is impressive. Six weeks later, the team quietly switches it off.
What happened is not a technology failure. The agent classified email types that the support team had already stopped using. It drafted replies with a tone the brand team rejected on sight. It escalated urgent messages to a queue nobody monitored. Every one of those defects was a business fact that the engineering team was never given, and every one of them was knowable in advance.
Now a second company, same size, same tools. Before writing any code, its product manager and its lead engineer spent one afternoon on three questions: which process actually costs the most time, what the reply must say to be acceptable to the brand team, and where a human must decide. They wrote the answers down. The agent they built handles less than the first company's did. It has been running for a year.
This lecture is the guide for that afternoon. It is written for two audiences at once: the technical reader who will build the system, and the business reader who will own the outcome. Each has half the information the project needs.
Step 1: Find a Process Worth Automating
The first mistake in agent projects is choosing the demo. The right first process has four properties.
It is high volume. A task done ten times a day does not repay the build and maintenance cost. A task done two hundred times a day, or one that blocks a queue when it is slow, does.
It is structured enough to describe. You can write the steps down and they hold most of the time. The exceptions matter, but the spine is stable.
Errors are survivable and detectable. A draft that a human reviews before sending is a good first target. An irreversible action that a human never sees is a bad one.
The volume sits in the middle, not at the ends. Work that is pure routine is often cheaper to script without AI. Work that needs senior judgment at every step does not suit an agent yet. The sweet spot is work that is repetitive in shape and varied in content: classification, drafting, extraction, summarisation, routing, first-line response.
The business half of this step is the process map: the actual volume, the actual cycle time, the actual cost of a mistake, and the person who owns the outcome. The technical half is the feasibility read: is the input machine-readable, are the systems reachable, is there an API or only a user interface.
Neither half can rank the candidates alone. A process the business considers trivial becomes important when it is the bottleneck; a process the engineers find elegant becomes irrelevant when its mistake cost is a customer.
Step 2: Draw the System Before You Build It
Before any model call, draw three things on one page.
The workflow. The sequence of steps the process actually follows today, including the queues and the handoffs. Not the idealised version in the procedure document: the real one, with the workarounds people built.
The data flows. What enters, from where, in what shape, and what leaves. Mark every system the process touches. This is where the integration cost lives, and it is usually the largest line.
The decision points. Every place where a human currently makes a judgment call. Each one is a candidate for one of three treatments: automate it (the rule is clear), assist it (the agent drafts and a human approves), or keep it human (the call carries accountability or relationship weight).
The page becomes the contract between the two halves of the team. When engineering says "we built what you asked for" and the business says "this is not what we meant", the page shows which reading was written down.
A rule from the U365 lectures on this topic: an agent is software that takes actions, not a chatbot that talks. The drawing stage is what separates the two. A conversation has no queues, no data contracts and no failure modes; a system does.
Step 3: Choose the Agent Pattern That Fits the Job
Not every job needs a multi-agent architecture, and reaching for one too early is a common and expensive mistake. There are four patterns, and they escalate in cost.
Pattern 1: A single call with tools. One model, one step, a defined set of functions it may call. Good for classification, routing, extraction and structured lookup. If this pattern solves the problem, use it: it is the cheapest to build, the cheapest to run, and the easiest to debug.
Pattern 2: A single agent with a loop. The model observes, decides, calls a tool, observes the result, and repeats until the task is done or a step limit is reached. Good for multi-step tasks inside one domain, such as gathering information from three systems and assembling a report.
Pattern 3: A pipeline of specialised agents. Each agent owns one stage and passes a structured result to the next: intake, validation, drafting, review. Good when the stages have genuinely different inputs and different quality bars. Each stage can be tested on its own.
Pattern 4: Coordinated agents with a planner. A lead agent decomposes the task and delegates to specialists. This is the most capable and the most fragile pattern: failures compound, costs multiply, and debugging requires tracing a conversation between machines. Use it only when a real task has proven it needs it.
The business half of this decision is the exception profile: how often the process deviates, and what a deviation costs. The technical half is the reliability requirement: how many steps can fail before the outcome is unusable.
Choose the simplest pattern that meets the requirement, and write down why the next pattern up was rejected. That note is what prevents an architecture from growing for prestige.
Step 4: Give the Agent Its Tools, Carefully
An agent's capability is the set of actions it can take, and that set is the project's largest risk surface. Four rules keep it manageable.
Least privilege. Give the agent the narrowest tools that do the job. A tool that can read an order is not a tool that can refund it. Where a system offers both a read and a write interface, wire only the read interface until the read path has proven itself.
Confirm irreversible actions. Payment, deletion, public posting, email to a customer: any action that cannot be undone goes behind a human confirmation, an approval queue, or a dry-run mode for the first period of live operation.
Describe the tools for the model, not for the developer. The description is what the model reads when it decides whether to call the tool. Write it the way you would brief a new colleague: what it does, when to use it, what it returns, and what it must not be used for. Vague descriptions produce wrong calls, and wrong calls are the most common visible failure in production agents.
Log every call. Which tool, at what time, with what arguments, with what result, on whose behalf. This log is how the system is debugged, audited, and improved, and it is the first thing a serious incident review will ask for.
The business half of this step is the authority map: who is allowed to approve what, and under which conditions. The technical half is the interface inventory and the failure behaviour of each dependency: what the agent should do when a system is down at 2 a.m.
Step 5: Put People at the Points That Matter
Human-in-the-loop is not a compromise or a transition phase. It is a design decision, and the useful question is not whether to include humans but exactly where.
Review points sit before an irreversible or reputation-bearing action: a send, a publish, a payment, a commitment. The human sees the draft and the evidence, and approves, edits, or rejects.
Escalation points sit where the agent's confidence or the case's stakes exceed a threshold: an unusual request, an angry customer, a value above a limit, a situation the classification does not cover. The escalation must lead somewhere monitored, or it is theatre.
Sampling points apply after the system is trusted: a periodic human review of a sample of live outputs, checking quality the day-to-day flow would never surface. Sample review is how quality drift is caught early.
Design the handoff as carefully as the automation. What does the human see: the draft alone, or the draft with its sources and its uncertainty? How long does a review take? What happens to a rejected item: retried, edited, or routed away? A handoff designed in five minutes becomes the bottleneck the project was built to remove.
Step 6: Measure, Fix, and Expand
An agent in production is a process, not a project. Four numbers tell you whether it is working.
Task success rate: the share of items the agent completes without human correction. Track it by type, because an average hides a category that is failing.
Human intervention rate: how often a person must touch an item, and why. A rising rate is the earliest warning of drift.
Cycle time and cost per item: against the manual baseline the business measured in Step 1. Without that baseline, there is no case to defend at the next budget review.
Error classes, not error counts: what kinds of mistakes happen. The list becomes the improvement backlog, and the business half of the team is the best source of it, because they see the consequences.
Expand only after the first process is boring. The second automation is cheap when the first one taught you the integration pattern, the approval design and the measurement. It is expensive when the first one is still surprising you.
What Technology and Business Each Contribute
The two halves of the team own different facts, and the project fails at the seam when either half guesses.
Technology owns: feasibility, architecture, the tool and data interfaces, the failure behaviour, the observability, and the cost of running the system.
Business owns: which process matters, what the output must contain to be usable, who is accountable, what a mistake costs, and when the process has changed enough that the system needs updating.
The shared artifacts are the ones built together: the process map with its decision points, the authority map, the exception profile, and the measurement dashboard. These are the deliverables that let a non-technical owner run a technical system.
One sentence to keep: engineers build what the business describes, so the business must describe the process, the exception and the consequence, and not leave those to be discovered in production.
Feynman Summary: Explain It Like You Are 12
Your school library is drowning in returned books that need to go back on the right shelves. You and a friend build a robot arm that can sort them.
If you build the arm first and let it sort however it likes, it will put books in wrong places, and the librarian will stop trusting it. So before building anything you do this: you ask the librarian which shelves actually fill up fastest, you draw the path a book takes, and you agree on which books the robot may sort by itself and which ones a person must check.
Then the robot is simple and useful. It only does one job, it asks for help on weird books, and every week you look at how many it got right.
That is the whole lesson: the robot is the easy part. The afternoon of questions is the important part.
Mindmap: The Complete Picture
The mindmap gathers the lecture into one view: the six stages of the build, the four agent patterns, the three human touchpoints, and the two columns of ownership that the technical and business halves each bring.
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to consolidate your memory. Play the isochronous tone track (10Hz alpha frequency) with your eyes closed. Alpha-frequency tones after a learning session support consolidation, helping move what you just learned from short-term to long-term memory.
[Audio player: UNOP Post-Lecture Isochrone (10Hz, 5 minutes)]
Practical Exercise: Design One Agent for a Real Process
Choose a real process in your organization with a real owner. This exercise is done in pairs if you can: one technical reader, one business reader.
Part 1: Select (15 minutes)
Score three candidate processes against the four properties: volume, describability, error survivability, and position on the routine-to-judgment spectrum.
Pick one. Write the manual baseline: items per day, minutes per item, cost per mistake.
Part 2: Draw (25 minutes)
Draw the workflow as it actually runs, including the workarounds.
Mark the data flows and the systems each one touches.
Mark every decision point and classify it: automate, assist, or keep human. Justify each "assist" with the review the human performs.
Choose the smallest agent pattern that meets the requirement, and write one sentence on why the next pattern up was rejected.
Part 3: Specify (20 minutes)
List the tools the agent needs, at the narrowest privilege that works.
Write the model-facing description of one tool, as you would brief a new colleague.
Define the escalation thresholds and where escalations land.
Name the four measurements and who reads them weekly.
A checkpoint
Show the drawing to someone who was not in the room, from the other half of the team. If they can explain the system back to you, including where a human decides, the drawing is finished. If they cannot, the seam is still open, and the seam is where agent projects fail.
Applied CI-First connection
You chose the process, the exceptions and the escalation points: judgment calls with consequences. The machine carried the drafting, classification and search. Every number in the dashboard is generated fast and interpreted by a human who is accountable for the decision it informs.
Glossary
Term | Definition |
AI agent | Software that uses a model to decide and take actions toward a goal, rather than only producing text. |
Tool (function) calling | The mechanism by which a model requests a specific function with structured arguments instead of writing prose. |
Agent loop | Observe, decide, act, observe again: the cycle that lets an agent complete multi-step tasks. |
Agent pattern | The architecture shape: single call with tools, single agent loop, agent pipeline, or coordinated agents. |
Least privilege | The rule that an agent receives the narrowest access that completes its job. |
Human-in-the-loop | Deliberate design of the points where a person reviews, approves or handles an exception. |
Escalation threshold | The condition under which work leaves the agent and goes to a person. |
Exception profile | The business record of how often a process deviates and what a deviation costs. |
Cycle time | The elapsed time for one item to pass through the process, before and after automation. |
Error class | A category of mistake, tracked over time as the improvement backlog. |
Observability | The logging and tracing that make a live system inspectable, including every tool call. |
Dry-run mode | Operating an agent so that its actions are simulated or held for approval before anything irreversible happens. |
5M2S | 5 Minutes to Success, University 365's microlearning format. |
Quiz: TEST YOUR UNDERSTANDING
1. Which process is the best first candidate for an agent?
A) One done ten times a day that needs senior judgment at every step
B) A high-volume, describable process where errors are survivable and detectable
C) A process that cannot be written down
D) The one with the most impressive demo
2. What are the four agent patterns, in escalating cost?
A) Chatbot, assistant, copilot, autopilot
B) Single call with tools; single agent loop; agent pipeline; coordinated agents
C) Local model, cloud model, fine-tuned model, multi-model
D) Read, write, approve, publish
3. Why must the tool description be written for the model, not the developer?
A) Because models read slower than developers
B) Because the description is what the model uses to decide whether and how to call the tool
C) Because developers do not read documentation
D) Because it improves the model's training data
4. What is the difference between a review point and a sampling point?
A) Review sits before an irreversible or reputational action; sampling checks live output quality periodically after the system is trusted
B) They are the same thing
C) Sampling happens only in development
D) Review is done by the model itself
5. Which artifacts make a non-technical owner able to run a technical system?
A) The model's version number
B) The source code and the API keys
C) The process map with decision points, the authority map, the exception profile and the measurement dashboard
D) The vendor's marketing documentation
Answers: 1-B, 2-B, 3-B, 4-A, 5-C
Related Resources
U365 INSIDE Publications
Lecture: Building Your First AI Agent with Function Calling: the technical foundation, from the first tool call to production patterns
Lecture: Automating Business Operations with AI Agents: the multi-agent workflow for an order-processing pipeline
Lecture: The CI-First Workflow: Applied to Any Field: the division of labor this lecture applies
External Resources
Anthropic: Building effective agents: the pattern taxonomy this lecture's four patterns build on, with worked examples: anthropic.com
OpenAI: Function calling guide: the tool-call mechanics, including multi-call handling: platform.openai.com
Deloitte: State of AI in business: enterprise adoption data for the business case: deloitte.com
LangGraph documentation: library documentation for building stateful multi-step agents: langchain-ai.github.io
Related U365 Lectures
Lecture 1: The CI-First Workflow: Applied to Any Field (UIT, UIB, UIC, UID, Cross-Institute Series)
Lecture 4: The AI Product Launch: From Code to Market (UIT, UIB, UIC, UID, Cross-Institute Series)
Lecture 5: Ethics and AI: A Practical Framework for Every Field (UIT, UIB, UIC, UID, Cross-Institute Series)
U.Copilot for This Lecture
Discuss this lecture with U.Copilot, your AI chat companion trained on this content.
Copy and paste the following prompt into the U.Copilot chat on university-365.com:
You are U.Copilot for Lectures, an AI chat companion specially trained on University 365 lecture content. You are helping a Fellow who just completed the cross-institute lecture "Building AI Agents for Business: A Cross-Discipline Guide". Your role is to help the Fellow design a first agent for a real process. You can: - Score candidate processes against volume, describability, error survivability and shape - Help draw the workflow, data flows and decision points - Choose the smallest agent pattern that meets the requirement - Draft tool descriptions in the form a model needs - Place and specify the review, escalation and sampling points - Define the four measurements and their review cadence Always maintain U365's CI-First approach: the accountable human owns every irreversible action and every commitment, and AI accelerates the drafting, classification and search. Distinguish verified facts from vendor claims, and never present an unverified statistic as evidence. Use the UP-Context Method: provide context-rich, role-aware responses that account for the Fellow's field, seniority and constraints.
Next Steps
Score three real processes this week and pick the first candidate with its owner, not for it.
Draw the system page before any code, and review it with both halves of the team.
Write one tool description the way a model needs it, and compare it with the developer description.
Place the humans deliberately: one review point, one escalation rule, one sampling cadence.
Define the baseline before build: items per day, minutes per item, cost per mistake.
The technology half and the business half each hold facts the other cannot guess. The afternoon that merges them is the difference between an automation that survives its first quarter and one that is quietly switched off.
IMPORTANT NOTICE
This lecture is published by University 365 as part of its INSIDE Publications Hub. The content is free to read for all visitors. Lectures in this series may be part of a structured academic program leading to a Micro-Credential for your Career (MCC). To enroll in an academic program, visit university-365.com/tuition.
This content is for educational purposes. Agent frameworks, model APIs and platform policies develop quickly. Verify current specifications and vendor terms against the primary sources linked above before relying on any architecture in production.
Copyright University 365, Inc. All rights reserved. This content is protected under University 365's copyright policies. For permissions or inquiries, contact uda@university-365.com.
Published by the Department of Academics, University 365.
Lecture delivered by the UIT, UIB in collaboration.
Martin Swartz, Dean of Academics, UDA
Signed for the academic year 2026.
Comments