From 50 Tools to 3 Write Channels

April 2026

When I first built Osistan — an AI operations assistant for my team — I gave it 50 tools. It could query databases, send Slack messages, create tasks, update wikis, fetch emails, generate reports, and more. Every capability I could think of, I exposed as a tool.

The LLM spent most of its intelligence choosing which tool to call.

The Problem

With 50 tools in the system prompt, the model was doing two jobs at once: understanding what the user needed, and navigating a complex tool selection maze. The result was predictable — it would pick the wrong tool, call tools unnecessarily, or chain multiple tools when one would do.

The cost wasn't just accuracy. Each tool had its own parameter schema, validation logic, and error handling. The codebase grew. Debugging got harder. Adding a new capability meant adding another tool, another schema, another set of edge cases.

The Insight

I realized the LLM didn't need 50 ways to act on the world. It needed to think clearly and then express its intent through a minimal interface.

The analogy that clicked: a human operator doesn't need 50 buttons. They need a keyboard. The keyboard is general-purpose — what matters is what you type.

Three Write Channels

I reduced the entire tool surface to three channels:

db_write(entity, operation, data) — All database mutations. Tasks, wiki pages, knowledge base entries, reminders. The entity and operation fields determine what happens. The LLM doesn't need to know the database schema — it expresses intent, and a deterministic layer routes it.

slack_send(target, message, blocks) — All communication. DMs, channel messages, thread replies, reactions. One channel, flexible enough for everything.

file_create(filename, content) — Reports, exports, generated documents.

Everything else — cron jobs, email parsing, deadline calculations, data fetching — runs in a deterministic layer that doesn't involve the LLM at all.

What Changed

The LLM stopped being a tool-selection engine and started being a thinking engine. Response quality improved immediately. The model could focus its full context window on understanding the user's request and formulating a thoughtful response, rather than navigating a tool maze.

Debugging became straightforward. Every LLM action goes through one of three channels, so every side effect is traceable. The deterministic layer handles all data fetching and computation, so there's no hallucination about data that doesn't exist.

Cost dropped too — fewer tokens spent on tool schemas in the system prompt, fewer retries from wrong tool selection.

The Takeaway

More tools doesn't mean more capability. It means more confusion for the model and more complexity for you. The right abstraction is one that lets the LLM focus on what it's good at — understanding intent and generating structured output — while keeping everything else deterministic.

Osistan now runs 24/7 on a Raspberry Pi 5, serving a team of 8 at ~$40/month. The 3-channel architecture is why it's reliable enough for production.