How to Make an AI Agent Without Writing Any Code
“How do I make an AI agent” is a reasonable question with a slightly annoying answer: mostly you don’t make one, you configure one — and the configuration is a settings exercise, not an engineering one.
Nothing below involves code. What it does involve is four decisions, and the fourth is the one that separates an agent you can trust with a real job from one you’ll quietly stop using after it emails the wrong person.
First: are you sure you need an agent?
Worth thirty seconds, because the answer is often no.
An assistant responds when you ask. You paste something in, it comes back, you decide what happens next. If that describes your task, you want a saved prompt or a reusable setup — that’s a smaller and faster thing to build, and it’ll serve you better.
An agent runs a multi-step job without you watching each move: it plans, it fetches what it needs, it revises, and it comes back when it’s finished or stuck. You want one when the task spans several steps and several places, and when you’d otherwise be the person ferrying information between them.
Meeting notes → tasks → filed in the right tool is an agent. “Rewrite this paragraph” is not.
Decision 1: Write the goal as a finished thing
The single biggest quality difference is describing the output, not the activity.
Weak: “help me with the weekly report.” Strong: “produce the weekly ops report in the same structure as the last four, leading with what changed, with any missing figure left as a marked blank rather than estimated.”
That goes in what most tools call The standing brief an agent reads before every run — the tool’s name for it varies (custom instructions, system prompt, the “Instructions” box, a project’s setup). It differs from a message you type in that it persists: you write it once and it applies to every future run, which is exactly why it’s worth writing carefully rather than dashing off. , and it’s worth ten minutes rather than one. Include how you want it to behave when something’s missing, because the default behaviour of a system finishing a job unattended is to fill the gap plausibly.
Say so explicitly: “if a number isn’t in the source, leave [MISSING] —
do not estimate.”
Decision 2: What it reads
Agents get much better when they can see your context, and much worse when they have to guess it.
Give it the reference material the job depends on: last month’s version, the style guide, the list of your team’s real terminology, the template you want matched. Most tools call this Files you attach to an agent so it can consult them on every run, rather than pasting them each time. Sometimes called grounding. The practical effect is that output stops sounding generic — the difference between “a status report” and “a status report that looks like ours.” , and attaching three good examples of past output does more than any amount of prompt-tweaking.
Keep it tight. Ten well-chosen files beat a hundred, and a stale document in there produces confidently outdated work.
Decision 3: What it’s allowed to touch
This is where an agent stops being a chatbot: you switch on connections to your actual tools — email, calendar, Drive or SharePoint, Slack or Teams, a CRM, a project tracker.
Two rules make this safe.
Grant read before you grant write. An agent that can read your drive and draft into a document is useful and nearly harmless. One that can send email and edit records is useful and consequential. Start with the first.
A connection inherits your access. It doesn’t get its own permissions — it gets yours. If you can see the shared folder with salary bands in it, so can the thing you just pointed at your drive. That’s not a reason to avoid connectors; it’s a reason to know what your own account can reach before you switch one on.
If nobody has told you in writing what your company allows here, that’s the real first step — a one-page AI policy exists for exactly this, and it’s the difference between a sanctioned tool and an awkward conversation.
Decision 4: Where it must stop and ask
Here’s the one that rarely appears in the tutorials, and the one that matters most.
Every agent platform lets you define checkpoints — moments where the run pauses and waits for you. Most people leave the defaults. Don’t.
Name the specific irreversible moments in your job and put a stop in front of each:
- Before anything sends to a person outside the team
- Before anything is deleted or overwritten
- Before anything is published, posted, or scheduled
- Before it spends money
Everything else can run unattended. The test isn’t “is this important?” — almost everything feels important. It’s “if this goes wrong, can I undo it in five minutes?” If yes, let it run. If no, make it ask.
An agent with no stops isn’t more autonomous. It’s just one whose mistakes you’ll find out about later, from someone else.
Where you actually click
The pattern is the same across tools even though the names differ: a custom GPT in ChatGPT, a Gem in Gemini, a Project in Claude, an agent in Microsoft Copilot Studio. All four ask you for instructions, then knowledge, then which tools it may use, then where to publish it.
Use whichever your company has approved rather than the one with the best reviews — an agent wired into the suite your work already lives in beats a better tool your data isn’t allowed to enter.
Test it against last week, not next week
Don’t debut it on live work. Run it on a job you’ve already completed, where you know exactly what the right answer looks like.
Then run it once more on an awkward one — the week the export was broken, the month with the weird outlier. The typical case tells you it works; the awkward case tells you how it fails, and that’s the thing you need to know before you stop watching it.
The takeaway
Making an AI agent is four decisions and no code: describe the finished output, give it the right things to read, grant it the narrowest access that does the job, and name the moments where it has to stop and ask.
Do the fourth one properly and everything else is recoverable. Skip it and you’ve built something that will eventually do exactly what you told it to, at speed, to someone who didn’t expect it.
Sources: platform capabilities described here are as documented by each vendor at the time of writing — Microsoft Copilot Studio’s build flow follows the same instructions → knowledge → tools → publish shape, and roundups of no-code agent builders show the pattern repeating across the category. These products change monthly; check your own tool. The four-decision framing and the “can I undo it in five minutes?” test are mine.
Related: What AI ‘Agents’ Actually Do is the plain-English explainer this assumes you’ve read. The First Job to Give an AI Agent — and the One to Keep covers choosing what to hand the thing once you’ve configured it — the natural next step after this one.