🤖 AI Assistants

A program of your own that you control with messages, connected to an AI model. It understands what you ask in natural language and responds or takes actions on your behalf.

Go from "using ChatGPT on the website" to "having an assistant that's all yours," running wherever you want, with your rules, your data, and your connected tools.

Assistant = interface (where you chat) + brain (the model) + hands (the tools). Personal means you own the code and where it runs.

The three parts that make up the assistant: the bot receives the message, the LLM decides what to do, and the tools perform real actions (search, save, send).

Understanding the design before coding prevents confusion. Each piece has a clear role, and you put them together one at a time until the whole thing works.

The flow is always the same: message → bot → LLM → (maybe) tool → response. The bot is the entry point; the LLM is the brain; the tools are the hands.

Telegram offers a free API for creating bots. You talk to BotFather, get a token, and your program can start sending and receiving messages.

Telegram is the simplest way to chat with your assistant from anywhere using your phone. No custom app, no interface to build.

BotFather creates the bot and gives you the token (treat it like a password). Your code reads messages (polling or webhook) and replies via the API. The token never goes into Git.

Connect the user’s message to a model API (Claude or GPT) and return the response. This is where the bot stops repeating scripts and starts to “think.”

It’s a leap in quality: the assistant understands vague requests, keeps context, and responds usefully instead of just reacting to fixed commands.

You send a system prompt (the personality) + the user’s message to the API and receive the text. The API key goes in an environment variable, never in the code.

Functions the assistant can trigger: direct commands (such as /clima) and tools that the model itself decides to call (search the web, do a calculation, save a note).

Without tools, the assistant only chats. With them, it does things in the real world. That’s what separates a chatbot from a real assistant.

A command is an explicit shortcut you type; a tool is a function the model calls on its own when needed. Each tool has a well-defined name, description, and parameters.

Bring the assistant up on your server (the VPS from Trilha 3) and keep it running all the time, instead of only while your computer is on.

An assistant is only useful if it's always available. On a VPS, it responds in the middle of the night, while you're traveling, without depending on your machine.

Reuse everything from the course: Docker (Track 4) to package it, systemd to keep it running, environment variables for secrets. The assistant becomes a service that restarts on its own.

The difference between an assistant, which only acts when you send it a message, and an agent, which has goals, acts on its own, and takes multiple steps to finish.

It’s the future of using AI: no more "question and answer," but "delegate a task and it gets done." Understanding this shift changes what you build.

Agent = goal + loop (think → act → observe → repeat) + autonomy. It can start actions without a direct human request at that moment.

Have the agent run at set times: a daily summary at 8 AM, checking emails every hour, timely reminders—all without you having to prompt it.

It’s what makes the agent proactive. Instead of waiting for you to ask, it shows up with what matters at the right moment, as a human assistant would.

Reuse cron and the systemd timer from Track 4. The agent "wakes up" on schedule, runs its routine, and goes back to sleep. Each scheduled task is a small routine.

Give the agent memory that survives the end of the conversation: it stores facts, preferences, and history in a database, then retrieves them when needed.

Without memory, the agent forgets everything with each message. With it, it gets to know you: it knows your projects, your contacts, and what was left pending yesterday.

Use Supabase (Track 2) to store memory. Before responding, the agent retrieves relevant context; afterward, it saves what it has newly learned.

Connect the agent to real services via API: read and send emails, create calendar events, and check tasks. Each integration becomes a new tool.

It’s what takes the agent out of the chat box and puts it into your real life. The more services it can reach, the more things it can solve for you.

Everything goes through APIs (Track 2) and tokens (Track 3). Start with a simple integration (send an email) and build from there. Handle each token with care.

Log every action the agent takes and monitor its health: what it decided, which tools it called, where errors occurred, and how much API usage cost.

An autonomous agent acts without you watching. Without logs, you don't know whether it got things right, got stuck, or messed up. Logs are your eyes when you're not looking.

View the logs with journalctl (systemd, Trilha 4). Record every decision and every tool call. Set up an alert for errors and high costs.

Treat the agent as a living project: observe how it behaves, add tools, adjust the prompt, and fix failures in a cycle that never ends.

A good agent isn't ready-made: it matures with use. Every mistake leads to an improvement, and over time it becomes more and more useful and reliable.

Use Git (Track 1) to version each improvement and deploys (Tracks 2-4) to safely publish new versions. Small commits, steady improvements.