Building a Simple AI Assistant with Make.com: What It Can Actually Do

I wanted to build a small AI assistant that I could send a question to and get a useful answer back without setting up a backend, deploying an app, or writing code.

That was the whole idea.

I wasn’t trying to build another ChatGPT. I just wanted a simple workflow that could receive a question, pass it to an AI model, and return the answer.

For this, I used Make.com for the automation and Mistral AI for the response generation.

The final workflow ended up being very small:

Webhook → Mistral AI → Webhook Response

It looks almost too simple when you see it working, but getting there taught me a few things about webhooks, field mapping, API connections, and how Make.com actually passes data between modules.

There were also a few moments where I thought something was broken when it was really just a small configuration issue.

Here is how the whole setup works and what I learned while building it.

Why I Chose Make.com for This

I could have built the same thing using Node.js, Python, or another backend framework.

But that would have meant creating an endpoint, installing packages, managing the API call, handling the response, running a server, and eventually deploying it somewhere.

For such a small experiment, I didn’t want all of that.

Make.com gave me a much faster way to test the idea.

You work visually. Add one module, connect another, map the data, and run the workflow.

That doesn’t mean there is no logic involved. There is still plenty to understand. The difference is that instead of writing most of the logic in code, you configure it through modules.

For this assistant, Make.com mainly had two jobs:

1. Receive my question.
2. Pass data between Mistral and whoever sent the request.

Mistral handled the actual AI response.

The Basic Workflow

The assistant starts with a webhook.

A webhook is basically a URL waiting for some data.

I send something like this:

{
  "question": "What is the capital of France?"
}

Make.com receives it and extracts the question field.

That question is then passed into the Mistral AI module.

Mistral generates the response.

The final Webhook Response module sends that answer back to the original request.

So the full flow looks like this:

Question → Make.com Webhook → Mistral AI → Answer

Once I understood that flow, the rest became much easier.

The Webhook Is the Entry Point

The first module I created was a Custom Webhook.

I called mine ai-assistant.

Make.com then generated a webhook URL.

That URL is important because it becomes the address of the assistant. Anything capable of making an HTTP POST request can send a question there.

That could eventually be a form, another app, a small website, a script, or another automation.

For testing, I just used a simple curl request.

The payload only needed one value:

{
  "question": "Explain machine learning in simple words."
}

I didn’t add API-key protection while testing because this was only a personal experiment.

For anything public or used by other people, I would definitely add some form of authentication. A public webhook with no protection can easily be abused if the URL gets exposed.

Connecting Mistral AI

The next step was adding the Mistral AI module.

Make.com already has a Mistral integration, so I didn’t have to manually build an HTTP request to the Mistral API.

I created an API key in the Mistral console, added a new connection inside Make, and selected Create a Chat Completion.

I used mistral-medium-2505 while testing.

At this stage, the Mistral module needs to know what message it should send to the model.

The role is set to User, and the content needs to come from the webhook.

This sounds obvious, but this is where I ran into my first real issue.

Make.com Has to See the Data Before You Can Map It

I expected the question field to immediately appear inside the Mistral module.

It didn’t.

The reason is simple: Make.com doesn’t know what your incoming webhook data looks like until it has received a sample.

So I had to go back to the webhook, click Detect new values, and send a test request.

Once Make received:

{
  "question": "What is the capital of France?"
}

the question field appeared as something I could map.

After that, I opened the Mistral module again, clicked inside the Content field, expanded the webhook data, and selected question.

Make inserted a mapped value that looked something like:

{{7.question}}

The module number may be different in another scenario. The important part is that the value is coming from the webhook.

This was probably the first moment where the workflow really started making sense.

The webhook wasn’t just triggering the scenario anymore. Its data was actually being passed into another module.

Returning the AI Answer

At this point, Mistral could generate an answer, but whoever sent the original request still needed to receive it.

For that, I added another Webhook Response module.

I set the status code to 200 and mapped the generated message from Mistral into the response body.

The response could simply return the text, but I preferred sending JSON because it is easier to use later from another application.

So instead of returning raw text, I used something similar to:

{
  "answer": "The capital of France is Paris."
}

That gives me a predictable response structure.

If I later connect a frontend or mobile app to this assistant, I already know the answer will be available inside an answer field.

Small decisions like this make future integrations much easier.

Testing the Whole Workflow

Once all three modules were connected, I clicked Run once.

Then I sent the webhook request again.

This part is quite satisfying because you can literally watch the request move through the scenario.

The webhook receives the request.

Then Mistral runs.

Then the response module runs.

A few seconds later, the answer appears back in the terminal.

At that point, I had a working AI assistant.

No server.

No deployment.

No backend code.

Just an HTTP request going into Make.com and an AI-generated response coming back.

Troubleshooting Common Make.com Errors

The workflow itself is simple, but a few small Make.com behaviours caused more confusion than the AI part.

Broken Module References

At one point I deleted and re-added a module.

After that, Make showed a warning about a module referencing another module that no longer existed.

This happens because each module has its own internal ID.

If a mapping points to Module 1 and you delete Module 1, adding a new module doesn’t necessarily give it the same ID.

The fix was not to ignore the warning.

I opened the affected field, deleted the old mapping, and selected the current field again.

That rebuilt the reference correctly.

The Webhook Returned “Not Found”

I also received a Not found response while testing.

Initially I assumed something was wrong with the scenario.

It wasn’t.

The webhook URL I was sending the request to wasn’t exactly the URL Make generated.

After copying the URL directly from Make instead of manually typing or editing it, the request worked.

So if a webhook suddenly says “Not found,” checking the URL should probably be the first step.

Getting “Accepted” Instead of an AI Answer

Another confusing response was simply:

Accepted

The request had reached Make, but I wasn’t getting the Mistral response.

During testing, Run once only listens for incoming data for a limited period.

I had clicked Run once, switched windows, waited too long, and then sent my request.

The listening session had already ended.

The easiest fix was to have the command ready first, click Run once, and send the request immediately.

Once the scenario is properly enabled, this problem goes away because the webhook is always listening.

Turning the Scenario Into an Always-On Assistant

Running the scenario manually is fine while testing, but it isn’t useful for an assistant you want to call throughout the day.

So the last thing I did was switch the scenario to run immediately as data arrives.

After that, Make.com no longer needed to be open.

I could send a request to the webhook at any time and get the Mistral response back.

That is the point where the experiment started feeling like an actual small service rather than just a Make.com scenario.

What You Can Build on Top of This

Right now, this assistant only answers questions.

But the same setup could be extended quite easily.

You could place a Telegram bot in front of it.

You could connect it to a contact form.

You could send the response to Slack.

You could store every question and answer in Google Sheets.

You could use different routes for different types of requests.

For example:

Email request → Generate email

Summary request → Summarize text

Idea request → Generate suggestions

Support request → Categorize and respond

The webhook and Mistral setup would stay mostly the same. Make.com would simply add more logic around them.

That is what I find useful about this approach.

You can start with something very small and keep extending it without rebuilding the whole thing.

Is This Really an AI Assistant?

Technically, it is a very basic one.

There is no long-term memory.

It doesn’t remember earlier questions unless I deliberately store and send that conversation history back to Mistral.

It doesn’t independently decide to use tools.

And it doesn’t perform actions unless I add more Make.com modules.

But that is fine.

The point of this project wasn’t to build a complicated autonomous agent.

It was to understand the basic mechanics behind an AI assistant:

Receive input → send it to a model → process the result → return an output.

Once that works, memory, external tools, databases, routing, approvals, and other features can be added one at a time.

Final Thoughts

What surprised me most was how little of this project was actually about AI.

Connecting Mistral was probably the easiest part.

Most of the work was understanding how data enters Make.com, how fields are mapped between modules, and how the final response gets returned.

That is useful because those same ideas apply to much bigger automation workflows.

The assistant I built is simple, but it is actually usable.

I can send a question to one URL and get an AI-generated answer back within seconds.

And because the workflow is sitting inside Make.com, I can now connect that same assistant to other tools without having to build the entire integration layer myself.

For someone experimenting with AI automation, that is a pretty good place to start.

Want to Build It Yourself?

If you want to try this setup yourself, I’ve also put together a complete hands-on guide where I walk through the Make.com scenario step by step, including the webhook setup, Mistral AI connection, field mapping, testing, and the errors I ran into along the way.

[Follow the complete hands-on guide →]