AI agents: real examples we use every day at a small business

An AI agent is a language model that you give tools (read email, query a server, create a file), a loop to keep using them until the job is done, and permission to act within certain limits. A chatbot only answers; a fixed automation always runs the same steps; an agent decides which step comes next based on what it finds along the way. Below are nine agents we use every day at GamzyHost, with what they decide on their own, what they ask us, and what has gone wrong, and at the end, how to pick the first one for your business.

Desliza para ver la figura completa

What an AI agent is, without too much theory#

Anthropic, the company behind Claude, separates two things in its guide Building effective agents. Workflows are systems where the model and tools follow paths defined in advance in code. Agents are systems where the model directs its own process and decides which tools to use. And it adds something we like because it cuts through the hype: in practice, they’re usually “just LLMs using tools based on environmental feedback in a loop.”

OpenAI, in its practical guide, breaks it down into three pieces: model, tools, and instructions. In our case, they look like this:

• Model: Claude, through Claude Code, running on a VPS with Windows Server.
• Tools: our own MCP servers that talk to the game panel, email, Discord, the GamzyHost website, and GamzyCloud (if you don’t know what MCP is, see what is MCP).
• Instructions: 49 skills. Each skill is a SKILL.md file with a description that tells Claude when to use it and instructions on how to do it, as defined in the Claude Code documentation. We cover it in depth in Claude skills.
• Permission: sensitive actions (replying to a customer, deploying the website) go through an approval. The system shows Ferran what it’s about to do and waits for his yes.

We call this whole setup Jarvis. Each example below is one of its skills or routines, with the same outline: problem, tools, what it decides on its own, what it asks, what it saves, and what to watch out for.

Agents that handle customers#

1. The customer inbox: everything pending in a single view#

• Problem: hosting customers write in from everywhere: Discord tickets, the website chat, email, the support AI, and now and then a payment dispute. Checking it all meant opening five tabs.
• Tools: it queries every channel at once (plus unpaid-invoice alerts and Stripe disputes) and pulls it all together.
• Decides on its own: what’s noise. It ignores automated notices and spam, and from the support AI it only flags complaints or someone asking for a human. It sorts by channel, customer, wait time, and topic.
• Asks: every reply to a customer. It prepares the final text and the system shows it to Ferran before sending.
• What it saves: before, a round through every channel; now, one sentence (“what do I have pending?”) and a short list.
• What to watch out for: that the agent understands what counts as pending. With tickets, it learned that if the customer’s last message is a “thanks” or an emoji, there’s nothing to reply to.

2. Company email#

• Problem: the contact inbox mixes customers, automated service notices, and advertising. The important stuff gets lost among notifications.
• Tools: an MCP that talks to the webmail API like a member of the team: list, search, read, reply in the same thread, and check whether the outgoing queue is working.
• Decides on its own: grouping automated notices into one sentence, ignoring spam, and putting messages from real people first.
• Asks: replying to a customer and anything involving money or contracts. It doesn’t treat a mass send to many customers as email: it hands it off to the campaigns skill, with unsubscribe and consent.
• What it saves: reading the whole inbox to find the two emails that matter.
• What to watch out for: dates (the skill forces it to give the one from the list and not make one up) and one hard rule: it never deletes emails.

3. Support tickets on Discord#

• Problem: answering a ticket properly requires checking who the customer is, which server they have, and whether they’ve paid.
• Tools: the ticket bot’s API (read with history and customer profile, reply, internal notes, assign, close) plus the server panel and payments.
• Decides on its own: which tickets are waiting for a reply, looking up the actual case before drafting, and adapting canned responses instead of pasting them.
• Asks: sending. It doesn’t promise refunds, compensation, or deadlines, and if the customer is angry or asks for something sensitive, it flags it before writing.
• What it saves: the back-and-forth between Discord, the panel, and Stripe to build the context for each ticket.
• What to watch out for: that it writes through the bot’s API and not directly into its database. If it did, the message wouldn’t be recorded as a team reply.

Agents that monitor and touch servers#

4. Game node status#

• Problem: customers’ game servers are spread across several machines. Finding out whether any of them was down, full, or oversold meant logging into each one.
• Tools: one call to the server panel’s MCP: whether each node responds, plus allocated servers, RAM, and disk. In detail mode, actual load, free RAM, and disk, read over SSH in read-only mode.
• Decides on its own: what’s serious, using written thresholds: disk above 85% is a warning and above 95% is urgent; 15-minute load above the core count is concerning; a machine that was powered on recently means asking whether it was on purpose.
• Asks: nothing; it only looks. Restarts and changes go through other skills with approval.
• What it saves: the SSH rounds. The summary is two or three sentences: first what’s wrong, then the number that matters.
• What to watch out for: that it doesn’t replace automated monitoring. Another process, with no AI, checks every 2 minutes that the nodes are responding; the agent is there to interpret. More in automating servers with AI.

5. Deploying the main website with a backup and rollback#

• Problem: gamzyhost.com is the website that sells. A badly built change takes it down, and doing it by hand means not skipping any steps.
• Tools: SSH and a fixed recipe: a dated backup, the change, the build, a restart, and a check that the homepage responds with no new errors in the logs.
• Decides on its own: if the build fails, it doesn’t restart: it fixes the error or restores the backup. The skill keeps a record of known traps, like files that look like they’re in use but are dead code.
• Asks: deploying. Approval is requested at the first change and covers the whole task.
• What it saves: the scares. It used to depend on remembering to make the backup; now it’s step 1.
• What to watch out for: that the local copy of the code falls behind. That’s why the agent notes in memory which files it touched.

It’s half workflow: the steps are fixed, but whether to continue, fix, or roll back is decided by the model reading the output of each one.

Office agents#

6. Creating Word, Excel, and PowerPoint documents#

• Problem: “make me a spreadsheet with…” is a frequent and boring request.
• Tools: it writes a Python script that generates the file with the usual Office libraries, runs it, checks that the file exists and isn’t empty, and drops it in the Files section of Jarvis’s web panel.
• Decides on its own: the document’s structure, formatting (bold headers, amounts in euros), and the file name with its date.
• Asks: nothing if the request is clear; the data comes from other skills that are already tested.
• What it saves: putting the document together. The slow part is asking for it.
• What to watch out for: that it cleans up temporary files when it’s done and doesn’t read the whole document out loud: it’s enough to say what it is and where it is.

7. Organizing projects, files, and memory#

• Problem: with an agent working all day, stray files and duplicate notes pile up fast.
• Tools: three skills. nuevo-proyecto creates each project in its place (folder, CLAUDE.md, memory entry, and indexes). revisar-orden looks for stray files, old temporary files, duplicate notes, and projects without an entry, and runs on its own every Monday. momento-de-organizarse is the phrase that kicks it all off at once.
• Decides on its own: anything reversible: moving its own files, clearing temporary files, merging duplicate notes (the leftover goes to an archive; memory is never deleted), and deleting leftovers from broken commands.
• Asks: moving or deleting Ferran’s files inside a project and changing the structure of areas.
• What it saves: in one pass, it compacted 61 repeated notes from a project into 9 without losing data; in another, it found 57 empty files named after badly escaped commands scattered across the project folders.
• What to watch out for: that it doesn’t delete what’s needed. It learned that the folder where files are received is off-limits even if it looks empty, and that reorganizing without first confirming the exact structure means redoing the work.

8. Reviewing videos, audio, and screen captures with Gemini#

• Problem: Claude can’t watch video or hear audio. To review the promos we make (sound effect timing, volume levels, on-screen text), we had to watch them one by one.
• Tools: our own script that uploads the file to Gemini with review instructions and returns a report with mm:ss timestamps, issues by severity, and a verdict (ready, touch up, or redo).
• Decides on its own: the analysis options (more frames per second for short promos where timing matters, high resolution only if there’s small text) and which instruction template to use.
• Asks: using Gemini’s most expensive model only if Ferran asks for maximum precision.
• What it saves: a first review pass. In our measurement on October 3, 2026, a 43-second promo cost $0.03 and took about 40 seconds.
• What to watch out for: false positives. Timestamps are approximate, and in long captures of a website Gemini flags problems that aren’t real, so anything serious gets checked in the video or the code before changing anything.

Agents that work at night#

9. The nightly research and the daily summary#

These are two routines that connect one day’s work with the next.

• Problem: what gets discussed during the day is lost if nobody writes it up, and keeping an eye on the competition across several projects doesn’t fit in the schedule.
• Tools: each day’s log, the memory (an Obsidian vault organized by project), web search, and Discord for notifications.
• How it works: in the early hours, the day’s summary gets written: what was requested, what was done, what’s pending, and the decisions. Another routine reads it, files what’s worth keeping, and tidies up the memory. Then comes the nightly research: the agent goes through the active projects, picks one or two actionable topics (not news), searches, cross-checks, saves a note in the project, and sends at most six lines over Discord: what it found, why it’s useful, and what to do.
• Decides on its own: topic, sources, and recommendation. It’s forbidden from spending money, writing to anyone, and touching servers.
• Asks: nothing; it only proposes.
• What it saves: hours of watching the competition. One night it spotted a new feature that several competitors were rolling out and recommended testing it on a small scale before deciding anything. Another night, a competitor’s price increase, and it noted that it wasn’t time to act yet.
• What to watch out for: conflicting sources. The agent marked a topic as “unverified” when the sources didn’t agree, instead of picking one. That’s what you want from an agent that does research on its own.

Summary table of the nine agents#

Look at the last column: none of them sends anything to a customer or changes production without approval. The ones that act on their own read, work on their own files, or stick to proposing.

How to pick your first agent#

If you run a small business and want to give it a try, don’t start with the flashiest agent. Start with the one that meets these three conditions:

1. Frequent task. Something daily or several times a week: checking channels, preparing a report, seeing if something is down. If it’s monthly, it’s not worth fine-tuning the instructions.
2. Verifiable result. You need to be able to check in a moment whether it did the job right: the list adds up, the spreadsheet has the right figures, the website responds. If you can’t, you won’t know when it gets things wrong.
3. Reversible. If it makes a mistake, it can be undone without harm. Summarizing is reversible; sending an email to a customer isn’t. The customer inbox is a good first agent if it only gathers and proposes, and a bad one if it replies on its own.

Anthropic recommends the same thing: start with the simplest option and add multi-step agents only when the simple approach falls short. If the task always follows the same steps, a fixed automation is all you need.

A sensible order: first an agent that only reads and summarizes (pending items, the status of your systems); next, one that creates new things without touching what already exists (documents, drafts); and last, with human approval, one that acts on something real (replying, deploying).

Desliza para ver la figura completa

Common mistakes when setting up agents at a business#

• Giving it permission for everything from day one. Our rule, learned through plenty of corrections: small, reversible things it does on its own; anything the owner decides, it proposes and waits for a yes.
• Not telling it what’s serious. An agent that checks servers without thresholds will tell you everything in the same tone. Write down the numbers: at what disk percentage it should warn you and at what point it’s urgent.
• Believing “it’s done.” One of the lessons ours has repeated most: check in production, in the log, or in the file before saying something is finished.
• Letting it learn without pruning. Our skills have a “Learned” section that the agent expands on its own when it makes a mistake. It works, but the nodes skill ended up with more than twenty nearly identical lines: if a tool fails, report it instead of staying silent. That lesson has 63 recorded repetitions. If the agent writes down the same thing over and over, the rule should move up to the general instructions and someone needs to clean up the copies.
• Credentials over chat. The agent never asks for or shows a key in the conversation. It first checks whether the credential is where it should be and, if it’s missing, asks for it to be placed somewhere secure.
• Mixing monitoring and agents. Anything that needs checking every few minutes is better handled by a simple process with no AI. The agent comes in to interpret or act.

You can see how all the pieces fit together (the VPS, Claude Code, the MCPs, the Obsidian memory, and the approvals) in how we built our own AI assistant. If you’re starting from scratch, the Claude Code guide is the first step, and we break down the costs in Claude pricing.