Most of the talk about AI agents is about customer support and software development. We were curious about a more boring and possibly more useful question: what would an AI agent do as an ordinary colleague in the operations of a small company? Not a chatbot on a website, but someone who orders lunches once a week, sends a summary in the morning and prepares notes for management in the evening.
We tried it out at a dental clinic. The result is Sindy, an internal AI assistant the team chats with just like with anyone else. She is a prototype built in a few weeks, not a finished product. That is exactly why she shows so clearly what works, what does not and where an AI agent makes real sense in day-to-day operations.
What Sindy does
Sindy is the face the team knows. Behind her runs a small platform of several specialised agents that share data and tools:
- Lunches: every week she processes the supplier's menu, opens the vote, closes the order on Monday morning, sends it to the supplier and prepares the cost split at the end of the month.
- Reports for management: daily overviews per area (staff, operations, finance, marketing), a running list of open items and a Monday summary of the week for the whole team.
- HR system: the HR agent works with the clinic's HR system through its official MCP server, and the Monday report pulls worked hours from it.
- Everyday conversation: in the team chat Sindy answers when someone addresses her and occasionally reacts briefly to a birthday or a good joke. Otherwise she stays quiet.
Lunches: the most rewarding use case
Ordering lunches looks trivial, but it has a fixed weekly rhythm, deadlines, e-mails with the supplier and plenty of small exceptions. The whole flow is now automated:
- The supplier e-mails next week's menu as an Excel file. Every day at 4 pm Sindy checks the mailbox and processes a new menu.
- She posts an intro message to the team chat with a vote for each day (Monday to Friday) underneath, and pins the intro so it does not get lost in the history.
- The change window closes on Monday at 7 am. Until then anyone can change their choice. Then Sindy counts the votes, generates the order for the supplier and a printable schedule for the reception, e-mails both and unpins the vote.
- Every weekday at 11 am she posts a short overview of who is getting which meal today. During the working day she watches for changes made after the order was sent and reports them to the reception by e-mail.
- On the first of the month she prepares the cost split for the previous month in Excel.
The most interesting part is the lunch exchange. After the deadline a lunch is paid for, so it is not cancelled, only handed over. Whoever can't make it tells Sindy, she offers the meal to the others, and the first person to say “I'll take it” gets it. The transfer flows automatically into the daily overview and the monthly cost split.
What matters is how Sindy changes orders. She may only touch the order of the person currently writing to her. Identity is not inferred by the model from the text; the tool resolves it from the message ID: message, sender, employee. Changing someone else's order is explicitly denied in her permissions. And her persona says she must not claim “done” until the tool returns OK.
Reports: from conversations to a management overview
The other half of the work is analytical. During the day the team writes about shifts, a broken device, running out of supplies or a query from an insurer. Management has no chance of turning that into an overview. Sindy does:
- Every hour a smaller model (Claude Haiku) goes through new messages and sorts them into signals by area: staff, operations, finance, marketing, other. For each one it sets an importance and whether action is needed.
- Every evening at 8 pm a larger model (Claude Sonnet) turns them into a daily report per area and updates the running list of open items.
- On Monday at 8 am the whole team gets a summary of the previous week: how many unique patients were treated, chair hours from the practice management system (aggregates only, no names), worked hours from the HR system and, with a wink, the week's best jokers by emoji reactions.
Reports show up on a simple internal dashboard that listens only on localhost and is exposed through Cloudflare Tunnel with login via Cloudflare Access. The finance and marketing agents can also answer ad-hoc questions against the practice's operational database, such as new patients by month, and send the result as an Excel file.
The HR system and the other agents
The agents have clearly separated roles: HR, operations, finance, marketing and an admin agent that looks after the platform itself. Management talks to them via Claude Code Remote Control, from a browser or a phone, each agent in its own session with its own permissions.
The HR agent is connected to the official MCP server of the clinic's HR system. It can read and change data (absences, for example), but its persona says writes happen only on explicit instruction and with a summary of the change up front. The HR system helps elsewhere too: Sindy uses it to match people in the chat to employees so the order and the cost split carry real names. Phone numbers are used only internally for matching and never appear in any output.
For the Monday report, though, we moved from MCP to the same system's REST API. A natural-language query over MCP is convenient for a person asking a question. A report that has to return the same numbers the same way every week needs deterministic calls.
How she is built
Nothing about Sindy is exotic, and that is on purpose:
- A Linux VM in Azure; every process runs under a single unprivileged user as systemd services and timers. A missed run catches up after a VM restart.
- Claude Code as the agent runtime. Scheduled jobs call
claude -pin non-interactive mode, interactive agents run as Remote Control sessions. Each agent is a directory with instructions and a permissions file. - A single SQLite database (WAL) as the shared bus: messages, votes, signals. Around it sit small scripts in Node.js and Python; the whole platform is roughly 2,300 lines of code.
- The conversation loop checks for new messages every 5 seconds but answers only 20 seconds after the last one, so it does not react to half a thought. It gets the last 30 messages as context and returns either an action or
NOOP. As a safeguard against loops, each agent is capped at 40 sent messages per hour, and its session resets daily. - Read-only access to the operational database: passwordless login via the VM's managed identity, a database role with read-only transactions and SELECT-only grants, a 20-second timeout. We treat the script-side guard as a bonus; the real protection lives in the database.
Two details we consider the most important. First, e-mails, phone numbers, national ID numbers and insurance numbers are stripped from the text before it is sent to the model. Second, installation is split into an unprivileged part and a root script that is installed once by hand and accepts only systemd units that match fixed rules. An agent running as the same user as the platform cannot grant itself more rights.
Personality in Markdown, rules in configuration
An agent's “personality” is nothing mysterious. It is a handful of Markdown files in the repository:
- Shared rules for all agents (never name patients, never print contact details, don't make things up, cite the source).
- A short role persona for the evening report, e.g. “operations assistant to the manager: group by topic, separate urgent / this week / someday”.
- A conversation persona: for Sindy “kind, friendly and a bit witty, writes briefly, informal, the odd emoji, not chatty”. Above all, it defines when to speak: answer when addressed; on a notable social moment you may react briefly; otherwise do nothing. Never pretend to be human.
Each agent's instructions are assembled from these parts with a single command, so shared rules are never copied by hand. Next to the persona sits a permissions file: which commands the agent may run, where it may write and what is denied (deleting, sudo, network tools, secrets). The persona describes how the agent should behave. Permissions define what it can technically do at all. You can rely on the first most of the time and on the second always.
What we learned
- Most errors come from integrations, not the model. Once, burgers arrived instead of spaghetti. We were sending the order as the supplier's own template re-saved by a library, and Excel then flagged it as corrupted. The supplier ignored the attachment, and the e-mail body only had dish numbers, which the supplier numbered differently. The fix was a clean new workbook and dish names right in the e-mail body, so the order is unambiguous even without the attachment.
- Identity is harder than it looks. One person voted from two devices, and an empty selection from one overwrote the order from the other. Now the latest real choice wins and deselecting overwrites nothing.
- Where you need the same result, use deterministic code. Name matching through the model fluctuated between runs, so a name once found is kept and the list is never overwritten by a version with fewer names. The report gets its numbers via REST, not via conversation.
- Idempotency wherever something leaves the system. The lunch close-out saves its progress step by step, so after an outage the order is never sent to the supplier twice.
- Operational basics from day one: a watchdog checks services and disk every 10 minutes and sends an e-mail; daily backups are kept for 14 days. An off-site copy of the backups is still on the to-do list, which honestly comes with a prototype.
When it makes sense (and when it doesn't)
Sindy came together quickly: the repository has 54 commits, the first one from 10 September 2026, and most of the work happened in the first week. The speed did not come from AI, though, but from choosing tasks with clear boundaries.
It makes sense when a process repeats every week, has a clear start and end (a deadline, a report), the inputs already exist (e-mail, chat, a database) and a mistake is reversible or a human sees it before it matters. Lunches, weekly summaries and triaging operational chatter tick every box.
It does not make sense where the agent would make irreversible decisions without human review, where data is missing, or where medical or legal advice is involved. Sindy's persona explicitly forbids such things and technically she has no access to them.
If you are considering a similar assistant, start with one boring process that costs someone an hour a week today. Try to write down exactly what the agent should do, from which data and who will see the result. If it fits on half a page, it is a good candidate. We are happy to help with design and delivery, see AI agents and automation.