Building My First No-Code AI Agent (4 Hours, 3 Failures)

I thought building my first AI agent would be easier than building an ordinary automation.

That was my first mistake.

I had already seen enough demonstrations to understand the basic idea.

Give an AI system a goal.

Connect a few tools.

Tell it what to do.

Let it make decisions.

And, supposedly, watch the work happen.

The reality was much less glamorous.

The first version didn’t behave the way I expected. The second version was technically working but made decisions I didn’t trust. The third version reminded me of something that is easy to forget when watching polished AI demonstrations:

An AI agent isn’t just an automation with a chatbot attached to it.

It has to interpret information, decide what to do, use the right tools and then produce an outcome that I can actually trust.

That is a much harder problem.

For this experiment, I wanted to keep things deliberately simple.

No coding.

No complicated multi-agent architecture.

No attempt to build an autonomous employee.

Just one small workflow that could take an incoming piece of information, understand it, classify it and prepare an appropriate next step.

The goal wasn’t to build something impressive.

The goal was to understand what actually happens when I give AI permission to make a decision inside a workflow.

Why I wanted to try a no-code AI agent

I’ve used ordinary automation concepts before.

They are wonderfully predictable.

If something happens:

Do this.

If a condition is true:

Do that.

Otherwise:

Take another path.

Traditional automation is excellent when the rules are clear.

The problem appears when the input isn’t clean.

Imagine receiving messages like:

“Hi, I’m interested in this but I’m not sure which option would work for me.”

or:

“Can you send me the details? I need this fairly soon.”

or:

“I already contacted you about this last week. Please check.”

A traditional workflow can handle those messages, but I have to keep writing rules for every variation.

This is where an AI agent becomes interesting.

Instead of defining every possible sentence, I can give the system a goal and some boundaries.

It can interpret the message and decide which predefined action makes sense.

That is the part I wanted to understand.

AI agents are moving from experiment to practical workflow

This isn’t just a niche experiment anymore.

McKinsey’s 2025 State of AI research found that 62% of respondents said their organizations were at least experimenting with AI agents. However, only 23% reported that their organizations were scaling an agentic AI system somewhere in the enterprise.

That gap is interesting.

It suggests that a lot of organizations are experimenting with agents, but relatively few have figured out how to deploy them broadly.

There’s a reason for that.

Building a demo is easy.

Building something trustworthy is harder.

PwC’s 2025 AI Agent Survey found that 79% of surveyed companies were already adopting AI agents, while 88% of the executives surveyed expected AI-related budgets to increase because of agentic AI.

So I don’t think the interesting question is:

“Can AI agents do things?”

They obviously can.

The more useful question is:

“Where should I allow an AI agent to make decisions, and where should I keep deterministic automation or human approval?”

That became the real lesson of my experiment.

What I actually wanted to build

I deliberately chose a boring use case.

That was intentional.

My first agent didn’t need to:

• run a business,
• manage finances,
• answer customers autonomously,
• send hundreds of emails,
• or control important systems.

I wanted a small message-triage agent.

The basic idea was:

Incoming message
↓
AI agent reads it
↓
Classifies the request
↓
Determines the appropriate category
↓
Prepares a suggested response/action
↓
Human reviews
↓
Action happens

That final human-review step mattered.

I wasn’t trying to prove that humans were unnecessary.

I was trying to determine whether AI could remove some of the repetitive thinking that happens before a human takes action.

The tool I used for the no-code experiment

For a concrete no-code implementation, Make’s current AI Agents system is a useful example.

Make describes its AI Agents as being built directly inside its visual automation environment, where an agent can interpret input, choose tools and adapt its actions. The current platform documentation also emphasizes visibility into the agent’s decisions and the ability to add rules or manual approvals.

Make says its current AI Agents can work across 3,000+ integrations and can be built without coding.

That makes it a reasonable environment for a first experiment.

But I want to make something clear:

The platform isn’t the interesting part of this experiment.

The workflow design is.

A badly designed agent remains badly designed regardless of which no-code platform I use.

Hour 1: I started too broadly

My first instinct was to make the agent “smart.”

I gave it a broad objective.

Something along the lines of:

Read incoming messages, understand what the person wants, decide what needs to happen and help complete the task.

It sounded great.

It was also terrible.

Why?

Because “help complete the task” isn’t a useful boundary.

The agent had too much freedom.

What should it do if the message is ambiguous?

What if the sender asks for something outside the workflow?

What if two categories seem equally appropriate?

What if the information is missing?

What if the requested action has consequences?

I had essentially created a job description instead of a workflow.

Failure #1: I gave the agent too much freedom

This was my first real lesson.

An agent needs a job, not a vague ambition.

So I narrowed it down.

Instead of:

“Handle incoming requests.”

I moved toward:

“Read an incoming request, assign it to one of four predefined categories, explain the classification briefly, and prepare a suggested next action. Do not send or publish anything.”

That was dramatically better.

The agent had a defined job.

Just as importantly, it had a defined boundary.

The difference between an automation and an agent

This was the point where the distinction became clearer to me.

A traditional automation might look like:

New form submission
↓
Condition
↓
If A → Action A
If B → Action B
If C → Action C

An agent looks more like:

New form submission
↓
Understand the request
↓
Determine intent
↓
Choose from available tools/actions
↓
Produce an outcome

The second workflow is more flexible.

But flexibility introduces uncertainty.

That’s the trade-off.

Hour 2: I discovered that instructions aren’t enough

My second version looked much better.

I added:

• the agent’s role,
• the categories,
• examples,
• things it should not do,
• and the required output format.

Then I tested several messages.

Most looked fine.

Then I deliberately gave it ambiguous input.

That’s where things became interesting.

Failure #2: The agent made a reasonable decision that I didn’t want

This is an important distinction.

The agent didn’t necessarily “fail” because its answer was nonsensical.

It failed because its interpretation wasn’t aligned with the workflow I wanted.

That’s a much more realistic AI problem.

An AI system can produce an answer that sounds perfectly reasonable while still making the wrong operational decision.

For example, if a message could belong to either:

Sales inquiry

or

General information

the agent might confidently choose one.

A human looking at the message might choose the other.

So I added another rule:

If the available information is insufficient to confidently classify the request, return “Needs Review” instead of guessing.

That single change made the system much more useful.

The “don’t guess” rule

This became one of my favourite parts of the experiment.

People often try to make AI systems sound confident.

For workflow automation, I increasingly think the opposite can be better.

A useful agent should know when to stop.

So I created three possible outcomes:

Confident

The information is clear.

Proceed with the predefined workflow.

Uncertain

The information is incomplete or ambiguous.

Send it for human review.

Out of scope

The request isn’t something this agent is allowed to handle.

Stop.

That sounds simple.

But this is exactly the kind of boundary that can prevent an AI workflow from doing something stupid.

Hour 3: I connected the tools

Once the reasoning part became more controlled, I connected the actual workflow.

The basic architecture was:

┌──────────────┐
│ Incoming     │
│ message      │
└──────┬───────┘
↓
┌──────────────┐
│ AI Agent     │
│ interprets   │
└──────┬───────┘
↓
┌──────────┼──────────┐
↓          ↓          ↓
Category    Needs       Out of
confirmed   review      scope
↓          ↓          ↓
Action     Human       Stop
review

This was where I started to appreciate why no-code agent builders are interesting.

I didn’t need to write a custom backend to connect every component.

The visual workflow made the relationships between the steps much easier to understand.

Make’s current documentation specifically positions its AI Agents as part of the same visual canvas used for automation, with the agent’s reasoning and workflow visible rather than hidden behind a separate system.

That matters when you’re debugging.

Failure #3: I trusted the output too much

This was probably the most important failure.

The workflow was working.

The agent was classifying messages.

The next step was preparing an action.

And because everything looked good during testing, I started thinking:

“Maybe I can just let this run.”

No.

That was exactly the wrong conclusion.

A successful test doesn’t prove that an AI workflow is safe to run unattended.

There are too many variables.

Real messages can contain:

• missing information,
• unexpected wording,
• conflicting instructions,
• sensitive information,
• malicious instructions,
• accidental ambiguity,
• or requests the workflow designer never considered.

So I kept the human approval step.

The agent could prepare.

It couldn’t independently execute the consequential action.

That distinction changed the design completely.

What I would build differently next time

My second attempt would start with a smaller question.

Not:

“What can an AI agent automate?”

Instead:

“What is one decision in my workflow that is repetitive, text-heavy and low-risk?”

That is a much better starting point.

Examples include:

• classifying incoming enquiries,
• extracting information from unstructured text,
• summarising internal messages,
• routing requests,
• identifying missing information,
• creating draft responses,
• turning notes into structured records.

Notice something?

Most of these tasks involve judgment, but not necessarily irreversible action.

That’s where I think beginner AI agents make the most sense.

My simple agent design formula

After going through the experiment, I’d describe a basic agent as five pieces:

1. Trigger

What causes the agent to run?

A message?

A form?

A schedule?

A new document?

2. Context

What information does it need?

Without enough context, the agent is guessing.

3. Decision

What does it actually need to determine?

Keep this narrow.

4. Tools

What can it access?

The fewer unnecessary tools, the better.

5. Boundary

What is it absolutely not allowed to do?

This might be the most important part.

Don’t give your first agent ten tools

This is another temptation I would avoid.

Once a no-code platform lets me connect many applications, it’s easy to think:

“More tools = more capable agent.”

Not necessarily.

More tools mean more possible actions.

More possible actions mean more opportunities for an unexpected decision.

For a first experiment, I’d rather give the agent:

one goal + two or three useful tools

than:

one vague goal + fifteen integrations.

Start narrow.

Expand only when the basic behaviour is reliable.

Where the statistics become interesting

The industry data actually supports this cautious approach.

McKinsey found that while 62% of respondents were experimenting with AI agents, only 23% reported scaling an agentic AI system somewhere in the enterprise.

In other words:

Experimentation is ahead of scaling.

That makes sense to me.

The first few hours of an agent project are relatively easy.

The difficult questions appear later:

• Who approves its actions?
• What data can it access?
• What happens when it is wrong?
• How are failures logged?
• How do I test changes?
• What happens when an integration breaks?
• Who is responsible for the output?

An agent shouldn’t automatically receive the same authority as the human whose work it is assisting.

The biggest misconception about “no-code”

No-code doesn’t mean:

no thinking.

It means:

less programming required to build the system.

That’s a huge difference.

The technical barrier is lower.

The design responsibility remains.

In fact, I would argue that no-code AI agents make workflow design more important because more people can now create systems that take real actions.

You don’t need to be a software engineer to build something powerful.

That is exciting.

It also means you need to understand what you’re giving the system permission to do.

When an ordinary automation is better

After this experiment, I wouldn’t use an AI agent everywhere.

If the rule is:

When a new invoice arrives, save the attachment to this folder.

I don’t need an agent.

Use automation.

If the rule is:

When a customer message arrives, determine whether it is a billing question, technical issue, sales enquiry or general question.

Now AI becomes more interesting.

That’s the dividing line I find useful:

If the workflow needs a fixed rule, automate it.

If the workflow needs interpretation, an agent may help.

And sometimes the best system is a combination of both.

The hybrid approach is probably the sweet spot

My ideal workflow isn’t:

AI does everything.

It’s:

Deterministic automation
↓
AI interprets messy input
↓
Deterministic rules validate result
↓
Human approval when necessary
↓
Deterministic action

That gives each component a job.

Automation handles what computers are already very good at.

AI handles ambiguous language and judgment-heavy classification.

Rules prevent obvious mistakes.

Humans handle exceptions and consequential decisions.

That feels much more realistic than the idea of handing an entire business process to an autonomous agent.

What four hours taught me

If I had to reduce the entire experiment to three lessons, they would be these.

Failure #1: My first prompt was too broad.

Lesson: Define the job narrowly.

Start Small Before Adding More

One lesson I learned from this experiment was that an AI agent becomes much easier to understand when its job is clearly defined. My first instinct was to make the agent handle too many things at once, but that only made the workflow harder to test and troubleshoot.

A better approach is to begin with one specific task, make sure that task works reliably, and only then add more capabilities. Make’s beginner guidance follows a similar principle: start with a single, well-defined task before expanding the agent’s responsibilities.

Make Academy’s guide to building AI agents

Failure #2: A reasonable AI decision can still be the wrong workflow decision.

Lesson: Define categories, examples and “don’t guess” conditions.

What I Learned From the Failed Runs

The failed runs taught me something important: building an AI agent isn’t only about connecting an AI model to a workflow. The way the agent is instructed matters just as much.

When an agent has access to tools, those tools need to be clearly described. The agent also needs to know what information it should receive, what it should return, and what it is expected to do at each stage of the task.

That gave me a much better way to think about troubleshooting. Instead of assuming that every unexpected result was a problem with the AI model, I started looking at the instructions and the workflow around it.

This is also why I found Make’s AI Agent best-practices guide useful. It covers practical areas such as tool descriptions, inputs and outputs, instructions, testing, and debugging.

The bigger lesson for me was simple: an AI agent needs a well-designed workflow around it, not just a powerful AI model inside it.

Failure #3: A successful test doesn’t mean the system should run unattended.

Lesson: Add boundaries and human approval before giving an agent meaningful authority.

Those three failures were more valuable than getting the first version right.

Because they changed how I think about AI automation.

Testing Was Part of Building

I initially thought that building the workflow was the main challenge.

It wasn’t.

Testing was.

An agent can look perfectly logical when you are designing it and still behave differently when it actually runs. That means testing individual scenarios, checking the outputs, and understanding where the workflow went wrong are just as important as connecting the tools in the first place.

Modern AI-agent builders are increasingly making this process more visible. Make’s current AI Agents experience, for example, brings building, testing and debugging into the same environment and provides visibility into the agent’s reasoning and the tools it uses.

That reinforced something I had already learned the hard way:

Building the agent is only the beginning. Testing the agent is where you discover whether the idea actually works.

Make’s AI Agents testing and debugging guide

A 30-minute version for beginners

If four hours sounds like too much, here’s how I’d approach a first experiment today.

Minutes 0–5: Pick one task

Choose something repetitive and low-risk.

Minutes 5–10: Define the output

What exactly should the agent return?

Don’t accept “do the task.”

Define the expected result.

Minutes 10–15: Add boundaries

Write:

• what it can do,
• what it cannot do,
• when it should ask for help,
• and when it should stop.

Minutes 15–20: Connect one or two tools

Don’t build the entire company.

Build one workflow.

Minutes 20–30: Try to break it

Give it:

• normal input,
• incomplete input,
• ambiguous input,
• irrelevant input,
• and deliberately awkward input.

If it survives those tests, you’ve learned something.

If it fails, you’ve learned even more.

Would I build another one?

Yes.

But I would build a smaller one.

That sounds contradictory after spending four hours on the first attempt.

It isn’t.

The first experiment taught me that an AI agent doesn’t become useful because it has more capabilities.

It becomes useful when its capabilities are bounded enough to trust.

That’s the part I didn’t appreciate at the beginning.

The flashy demo is the easy part.

The boring rules are the valuable part.

The checklist I’d keep beside me

Before publishing or activating a no-code AI agent, I’d ask:

• What exactly is the agent responsible for?
• What information can it access?
• Which tools can it use?
• What decisions can it make?
• What decisions must it never make?
• What happens when it isn’t confident?
• Can a human approve consequential actions?
• Can I inspect what the agent did?
• Can I test it with bad inputs?
• What happens when an integration fails?
• How will I know if its behaviour changes after an update?
• Can I turn it off quickly?

If I can’t answer those questions, I’m probably not ready to let the agent run unattended.

The real value of a first AI agent

I went into this experiment expecting to learn how to build an AI agent.

I actually learned something slightly different.

I learned how to design boundaries around AI.

That’s a more useful skill.

AI agents are getting easier to create. No-code platforms are lowering the technical barrier, and businesses are experimenting with them at an impressive rate. McKinsey’s research shows substantial experimentation, while PwC’s survey shows significant organizational investment and adoption.

But the fact that something can be automated doesn’t mean it should be.

My first agent didn’t need to be autonomous.

It needed to be useful.

It needed to make one repetitive part of a workflow easier.

And, most importantly, it needed to know when not to act.

That’s probably the biggest lesson I’d give anyone building their first no-code AI agent:

Don’t start by asking how much work you can hand to the agent. Start by asking how little responsibility it needs to have to create real value.

Once that works, expand.

One capability at a time.

One tool at a time.

One permission at a time.

And test every step.

Because the goal isn’t to build an AI agent that can do everything.

The goal is to build one that does one useful thing reliably enough that I actually want to keep it running.