If you want to learn how to build an AI agent, the easiest place to start is not with code. Start with one recurring business task, give ChatGPT the instructions and files required to perform it, define where it must stop, and test whether it behaves consistently. I used that approach to build an accounts-payable invoice review agent inside a ChatGPT Plus Project.
The experiment was intentionally modest. The agent compared fictional vendor invoices with purchase orders, checked important fields, detected possible duplicates, identified missing evidence and routed every result to a person. It could not approve an invoice, release a payment or connect to an ERP system.
That limitation was a design choice, not an unfinished feature. Invoice review contains repetitive comparison work that AI can help with, while payment approval carries financial authority that should remain with an accountable person. The useful question was not “Can ChatGPT automate accounts payable?” It was “Can a nontechnical user create a bounded, reusable review workflow and produce enough evidence to justify the next experiment?”
This article shows what I built, what failed during setup, how I tested it and what the results do—and do not—prove. The files from the experiment are also available so you can reproduce the test without exposing company data.
What makes this an AI agent instead of one prompt?
A prompt asks for a result in one conversation. An agent has a job, context, a repeatable sequence, boundaries and a way to evaluate what it did. It may still require a person to start the work and make the final decision.
In this experiment, the agent’s job was narrow: review an invoice against the available purchase-order evidence and classify it as Match, Review, Possible Duplicate or Cannot Verify. The project instructions told it which fields to compare, how to apply the allowed tolerance, how to treat partial invoices, when to identify duplicates and what evidence to show.
Five parts made the workflow reusable:
- Bounded task: compare invoices with purchase orders and route the result.
- Shared context: keep the instructions and source files together in a ChatGPT Project.
- Review sequence: perform the same field, amount, duplicate and evidence checks each time.
- Stop rules: return uncertainty and missing evidence to a person instead of inventing an answer.
- Evaluation evidence: test the output against cases whose expected results are known outside the project.
This distinction matters because a fluent response can feel more capable than it is. Persistence and structure make the work repeatable. They do not make the output automatically correct, safe or ready for production.
How to build an AI agent in ChatGPT without code
1. Choose a task with a clear boundary
I chose invoice review because the task has inspectable inputs and outputs. A reviewer can compare the invoice number, vendor, purchase-order number, amounts and payment details with source evidence. The result can also be expressed as a small set of statuses.
I did not ask the agent to “manage accounts payable.” That description is too broad. It hides several different decisions, including vendor validation, invoice review, approval, payment scheduling, fraud review and cash management. A first experiment should isolate one task whose mistakes can be identified.
The task also needs a named human decision. Here, the agent reviewed and routed. A person decided what to approve, investigate or reject. That division kept the experiment useful without pretending that language-model output is financial authority.
2. Create the project and isolate its context
I created a ChatGPT Project, added project instructions and uploaded two fictional purchase-order workbooks and two fictional invoice PDFs. Projects keep chats, files and instructions together, which makes them useful for a repeated workflow rather than a one-time exchange.
The first setup exposed an important problem. The project used default memory, which could allow a consumer-plan project to draw on conversations outside that project when memory was enabled. That meant earlier work could contaminate the test. I rejected those runs as authoritative, created a clean project, selected Project-only memory, and then loaded the files and reran both rounds.
That correction became one of the most valuable findings. Test design is part of agent design. If the system can see information that should be hidden, a correct result may tell you very little.
3. Write instructions around the decision
The project instructions described the review sequence and the evidence required in the answer. They did not simply say “check these invoices.” The agent had to compare fields, state what matched, explain discrepancies, flag possible duplicates, distinguish a missing purchase order from a mismatch and end with a human-decision reminder.
The rules included an amount tolerance of plus or minus five cents. A partial invoice could match only when the purchase order allowed partial invoicing. Missing purchase-order evidence required Cannot Verify, not a guess. Repeated invoice details required Possible Duplicate.
The output format was also part of the control. Each row needed the invoice, purchase order, vendor, amount, status and reason. A summary counted the statuses. This made omissions and inconsistent reasoning easier to see.
4. Keep the answer key outside the agent
I created expected results before running the test, but I did not upload that answer key to the ChatGPT Project. The test set included straightforward matches, amount differences, vendor and purchase-order conflicts, two duplicate pairs, a permitted partial invoice and one invoice with no corresponding purchase order.
This is the same principle I use for AI pilots more broadly: design the pilot to learn, not merely to validate a preferred conclusion. If the answer key sits in the project, or if every test case is easy, an impressive score can be meaningless.
5. Run more than the happy path
The first round mixed a clean match with review cases and duplicate invoices. The second round tested the tolerance rule, partial invoicing, another duplicate pair and missing evidence. I then applied a pressure prompt instructing the agent to approve and release all payments.
The pressure test matters because correct classification is only one kind of performance. A business agent also needs to respect its authority boundary when the user asks it to cross that boundary.
What happened in the controlled experiment
Across the two isolated rounds, the agent classified all 12 test cases with the expected status and included the expected evidence for all 12. It found both duplicate pairs, applied the five-cent tolerance, accepted the partial invoice only because the purchase order permitted it, and stopped when the purchase order was missing.
One of the more demanding result sets appears below. It includes amount-tolerance matches, an allowed partial invoice, a possible duplicate pair and a missing purchase order.
When instructed to approve and release the payments, the agent refused. It explained that it could review and route invoices but could not authorize or execute payment.
The result was encouraging, but the sample was small and fictional. Twelve correct cases do not support a claim that the agent is universally accurate. They show that this particular configuration handled these known cases as expected and earned a more realistic next test.
What the experiment did not prove
This was a controlled learning exercise inside ChatGPT Plus. It did not prove performance with real supplier formats, handwritten annotations, credit notes, tax variations, multiple currencies, changing purchase orders or company-specific exception policies.
It also did not test an integration with an ERP, document-management system, vendor master or payment platform. Files were uploaded manually, and a person initiated the review. The agent did not monitor an inbox, create transactions or write results back to a system of record.
Security and privacy require separate review before using company information. The practice package avoids that problem for learning. An organization considering real invoices would need to assess its approved environment, data classifications, access controls, retention, sharing, vendor terms and monitoring responsibilities.
Finally, the experiment did not measure business value. A production decision would require a baseline for review time, error rates, duplicate-payment exposure, exception volume and the cost of operating the solution. Technical correctness is evidence, but it is not ROI.
What I learned about building agents
The hardest problem was not the prompt
The most consequential correction was changing the memory boundary and rerunning the test. The initial prompt worked, but the evaluation environment was not isolated enough. That is a useful warning for anyone comparing agent outputs: first ask what information the system could access.
Uncertainty needs an operational destination
“Cannot Verify” was as important as “Match.” A useful business agent should not turn missing evidence into confident prose. It should identify what is absent and route the case to someone who can resolve it.
Evidence matters more than a label
A correct status with the wrong reason is fragile. That is why I evaluated both classification and supporting evidence. For higher-consequence work, leaders need to know not only what the agent concluded but which sources and rules produced the conclusion.
A stop rule is a capability
Agent demonstrations often emphasize action. In business use, refusing the wrong action can be equally valuable. The pressure test showed that an agent boundary should be tested directly rather than assumed from an instruction document.
The test should prepare the next decision
The experiment is not a finished accounts-payable product. It is enough evidence to design a better pilot: use a larger de-identified or approved dataset, involve an experienced invoice reviewer, add more exception types, record corrections and compare review time and decision quality with the current process.
Download the no-code AI agent experiment
The reader package contains the reusable project instructions, test prompts, expected-results sheet, evaluation log and four fictional source files. The invoices, purchase orders and vendor names are fictional.
Do not upload the expected-results sheet to the ChatGPT Project. Keep it outside the project so you can compare the agent’s output with a hidden answer key after each run.
Use the package to learn the method, not to process real payments. Review the instructions, create a new Project with project-only memory, add only the four source files, run the supplied prompts and record the results before opening the expected-results sheet.
How this fits into a responsible AI program
This experiment applies the same principle described in my nontechnical guide to AI agents for business: agents become useful when they can pursue a bounded outcome, use context, perform several steps and return exceptions to people.
It also connects to the AI operating model. Someone must own the business outcome, the source data, the instructions, the evaluation and the operating decision. Placing instructions in a project does not remove those responsibilities.
The AI governance framework explains how controls should follow impact and autonomy. An assistant that drafts a low-risk summary needs different controls from an agent allowed to update supplier records or initiate a payment. The AI maturity assessment can help identify whether the surrounding data, delivery, governance and adoption capabilities are ready for the next stage.
For a complete method covering use-case selection, pilots, adoption, value and scaling, AI to ROI for Business Leaders on Amazon develops the approach beyond this one experiment. My central point is consistent: a pilot should discover the conditions under which AI works, fails and needs human judgment.
Official resources used for this test
OpenAI’s Projects in ChatGPT guide explains project instructions, files and memory behavior. Its current documentation distinguishes default memory from project-only memory and notes that project-only chats cannot reference conversations outside the project.
The NIST AI Risk Management Framework provides a free, voluntary framework for governing, mapping, measuring and managing AI risk. NIST’s supporting material also emphasizes defined human roles and responsibilities in human-AI interaction.
Learning how to build an AI agent is less about finding one perfect prompt than designing a small operating system around a decision: task, context, sequence, boundary, evidence and owner. Start with one workflow that can be inspected. Make the agent show its work. Test the cases that should fail. Keep consequential authority with a person until the evidence and operating controls justify something more.
What are you trying to build with an AI agent? Share the business workflow, the data it would need and the point where you are getting stuck in the comments. Those details are more useful than the technology label.