DEV Community: Stephen Phillips

Your Small Business Agent Does Not Need Every Tool

Stephen Phillips — Sun, 16 Aug 2026 16:41:02 +0000

A small business usually does not need a smarter agent first. It needs an agent with fewer ways to get lost.

That sounds backwards when the default pitch is “connect everything”: email, CRM, database, website, accounting, calendars, search, social, and a dozen specialist services. MCP makes those connections easier. A client can discover tools from servers instead of shipping a custom integration for each one.

The temptation is to expose the whole toolbox and let the model choose.

For a five-person business, that is the wrong default. The first useful agent should see a small, task-specific set of tools. It should prepare work before it performs side effects. When the tool list changes, that change should be visible and reviewable.

The problem with a giant toolbox

Tool descriptions sit in the agent’s working context. A large catalogue costs tokens. The bigger cost is ambiguity. If an agent can search five systems, update three records, send messages, and edit a workflow, every request becomes a routing problem before it becomes a business problem.

Familiar failure modes:

The agent picks a tool that is technically valid but operationally wrong.
A read-only request shares context with write-capable tools.
Similarly named tools point at the wrong account or environment.
A server update adds a tool and quietly changes the agent’s choices.
Nobody can reconstruct why a particular action was selected.

The MCP tools specification supports discovery through tools/list and lets a server notify clients when the tool list changes. That is useful for growth. It also means the action surface is not static. Treat tool exposure as configuration, not a one-time onboarding step.

The question is not “Can this agent access the system?” It is “Which two or three capabilities does this job need right now?”

Route by job, not by vendor

Imagine a local company that receives quote requests through a WordPress form. The owner wants an assistant to sort them each morning and prepare replies.

A broad setup might expose WordPress, email, CRM, calendar, files, web search, and accounting. Plenty of options for the model. Plenty of permissions for the owner to worry about.

A routed setup gives the quote-triage task only:

read_new_quote_requests
lookup_customer_record
prepare_quote_reply
queue_reply_for_approval

The underlying services can stay the same. A routing layer presents a narrow contract for this task. Email-send is not available while the agent is classifying requests. Accounting tools are not in context at all.

This is not a claim that models stop making mistakes. It makes the mistakes smaller. A wrong choice from four tools is easier to inspect than a wrong choice from forty.

A useful router can select by:

the user’s task (“triage today’s enquiries”)
data sensitivity
whether the next step is read-only or changes state
business hours or approval policy
how complete the request is

The router should return a tool set plus a short reason. That reason becomes part of the run record: quote_triage -> read_quotes, lookup_customer, prepare_reply.

Keep read and write paths separate

The cleanest first boundary is between gathering information and changing something.

A read path can collect a form submission, retrieve the matching customer record, and draft a response. A write path can create a CRM task or send an email, but only after a person approves the proposed action or a clearly defined policy allows it.

That separation matters more than a clever system prompt. A prompt can say “do not send email without approval.” A permission boundary can make sending unavailable until approval exists.

In an MCP system that can mean separate servers, separate credentials, or a proxy that filters tools based on workflow state. Implementation varies. The operating rule does not: do not give a classification step the ability to perform the final action.

n8n’s human-in-the-loop tool patterns are a practical model here. The workflow can pause at a sensitive tool call, ask for approval in Slack/Telegram/chat, then resume with the approved action. That bridges “assistant only drafts” and “assistant runs unattended.”

Make tool changes boring and visible

Dynamic discovery is useful when a business adds a service. It becomes dangerous when the tool list changes and nobody notices.

Put the exposed tool set in a versioned config file, even if the underlying MCP servers are dynamic. For each workflow, record something like:

workflow: morning-quote-triage
allowed_tools:
  - read_new_quote_requests
  - lookup_customer_record
  - prepare_quote_reply
  - queue_reply_for_approval
blocked_tools:
  - send_email
  - edit_wordpress
  - create_invoice
policy: approval-required-for-external-messages

When a tool is added, removed, or renamed, write a small change record. Test the workflow with a fixture, then ship the new set. Ordinary release hygiene. An agent’s tool catalogue is part of its application surface.

The same applies with a local model. Ollama supports tool calling, but a local model does not remove the need for boundaries. It can make the data path more private and cost more predictable. It cannot decide whether send_customer_email is appropriate just because the schema is valid.

Store a receipt for every route

A useful run record does not need private customer content. Store the operational facts:

workflow name and version
request category
tools made available
selected tool and redacted arguments
approval state
duration and result status
final human or system outcome

That record answers the questions an owner eventually asks: Why that action? Which tools were available? Did a person approve it? Was the failure in the model, the router, or the downstream service?

Do not log full email threads or customer records by default. Prefer identifiers, hashes, and small redacted summaries. Debug the workflow without creating a second copy of the business’s sensitive data.

A small pilot you can finish in a week

Start with one repetitive workflow that has a clear finish line. Quote triage, appointment requests, or a daily content queue beat “run the business.”

Day one: write the desired outcome and the actions that stay human-approved.

Day two: expose only read and draft tools; run a few representative examples.

Day three: add the approval queue and a receipt record.

Then measure the boring things: time saved, wrong classifications, approval turnaround, failed tool calls.

If the workflow is reliable, add one capability at a time. If it is not, shrink the tool set before you change the model.

That last step is easy to skip. People often respond to bad choices with another instruction, another retrieval step, or a larger model. Sometimes the fix is removing seven tools the task never needed.

MCP makes connected tools easier to build. Good routing makes them easier to operate. For a small business, the practical win is not an agent that can do everything. It is an assistant with just enough access to finish one job, that asks before it crosses a boundary, and leaves evidence when something goes wrong.

Source notes

MCP tools specification — discovery, invocation, notifications/tools/list_changed
MCP security best practices — least privilege, consent, tool access
Ollama tool support
n8n human-in-the-loop tools
Distinct from HappyMonkey drafts on approval gates, receipts/observability, and draft-queue-first workflows: this piece is about routing and versioning the available tool surface before invocation

The Safest First MCP Workflow Is a Draft Queue, Not an Autonomous Agent

Stephen Phillips — Sun, 16 Aug 2026 16:40:58 +0000

Most small businesses do not need an autonomous agent.

They need the next customer reply drafted, the right product notes found, and a human who can still sleep knowing nothing weird went out overnight.

That is how I would start the first useful MCP project.

The tempting demo wires the agent to CRM, inbox, calendar, WordPress, analytics, and payments. It looks powerful. It also creates a large surface for wrong tool choices, accidental writes, duplicate sends, and questions nobody can answer later:

Which tool did the model call?
What information did it use?
What would it have changed if nobody stepped in?
Can we replay the decision without dumping the whole customer record into a log?

For a small team, the safer start is a draft queue. The agent researches and prepares a proposed action. A person approves it. Only then does a narrow workflow perform the side effect.

Less spectacular than an autonomous agent. More likely to survive a real Monday.

MCP makes the boundary easier to define

The Model Context Protocol gives apps a standard way to expose tools to language models. A tool has a name, description, and input schema. It can query a database, call an API, or run a computation.

That standardisation helps. It does not decide which tools an agent should see, or which calls may change state. Those are application decisions.

Treat every MCP tool as one of two things:

Read or prepare — search the knowledge base, look up an order, summarise a policy, draft a reply, assemble a WordPress post.
Side effect — send email, publish content, issue a refund, update a CRM record, delete something.

Category one is a good pilot surface. Category two stays behind an explicit approval boundary until the workflow has earned trust.

The protocol can make integrations interoperable. It cannot make a sloppy permission model safe.

A concrete first workflow: enquiries to approved replies

Imagine a five-person agency receiving enquiries from a website form.

The first agent version needs only four tools:

search_services — read the approved service catalogue
find_faq — retrieve answers from maintained FAQs
lookup_enquiry — read one enquiry by internal ID
create_reply_draft — write a proposed reply into an approval queue

Notice what is missing: no send-email tool, no unrestricted filesystem tool, no “read every customer,” no inventing prices from a private spreadsheet.

A worker can follow a boring, inspectable sequence:

Receive an enquiry ID, not a pasted customer dump.
Read the enquiry and the relevant approved service notes.
Draft a reply with links to the source notes it used.
Store the draft with status needs_review.
Notify a human reviewer.
After approval, a separate deterministic workflow sends the exact approved text.

The model earns its keep by removing repetitive search and first-draft work. Approval is a state transition, not a polite line in the system prompt.

Use shadow mode before the agent writes

A useful intermediate stage is shadow mode.

The agent runs on real or representative requests but cannot create even a draft in production. It writes proposed tool calls and outputs to a review log. A human compares that with what they would have done.

For two weeks, track simple measures:

How often did it choose the right source?
How often did the draft need a factual correction?
Which requests were ambiguous?
Did it ask for information it should not have needed?
How many proposed actions would have been unsafe if executed automatically?

That gives evidence instead of vibes. It also surfaces missing business rules. Repeated edits often mean a documentation problem, not a model problem.

Only after shadow results look acceptable should the workflow create needs_review drafts. Automatic side effects come later.

The approval queue is a product feature

Do not bury approval in a chat transcript. Give it a small, durable record.

A draft queue entry might look like:

{
  "id": "reply-2026-0713-0042",
  "request_id": "enquiry-1842",
  "status": "needs_review",
  "proposed_action": "send_email",
  "recipient": "customer@example.test",
  "body": "A human-readable draft goes here",
  "source_refs": ["services/websites", "faq/migrations"],
  "created_by": "agent",
  "approved_by": null,
  "created_at": "2026-07-13T09:30:00Z"
}

Schemas will vary. The fields that matter are action, scope, source references, and state. Approval should mean “approve this exact proposed action,” not “the agent may now freestyle with email.”

When a reviewer edits the draft, record that too. Edits are feedback and audit trail.

Keep the side-effect tool deliberately dull

The final send step should be a narrow integration with boring validation. It accepts a queue ID, loads the approved record, checks status is approved, confirms recipient and body have not changed, and sends once.

It should reject:

unapproved records
expired approvals
changed recipients
duplicate queue IDs
missing source or audit metadata

Idempotency matters. If a network timeout hits after the provider accepted the email, a blind retry can double-send. Store a provider message ID or another durable operation key and resolve the previous attempt before sending again.

This is ordinary workflow engineering. That is the point. MCP should connect the agent to a workflow; it should not replace the workflow’s invariants.

Where local AI fits

A local model (for example via Ollama) can be a good fit for drafting and classification when you want less data movement or lower recurring API cost. Ollama’s tool-calling support makes structured tools practical, and its MCP examples point the same way: reason over a controlled tool surface.

“Local” is not the same as “private by default.” The moment a tool hits a cloud CRM, email provider, hosted observability service, or external search API, selected data leaves the machine. Logs can leak data too.

The useful question is not “is the model local?” It is:

What is the minimum information this step needs, and which system is allowed to receive it?

Pass an enquiry ID rather than an export. Return the relevant FAQ paragraphs rather than the whole document store. Redact secrets before logging model input. Keep high-risk tools out of the worker’s catalogue entirely.

A 30-day pilot plan

Week 1: define the boundary. One repetitive workflow. List read tools, draft output, approval owner, and unacceptable actions.

Week 2: build shadow mode. Capture proposed tool calls and drafts without writing to production. Build a small evaluation set from representative, sanitised requests.

Week 3: add the approval queue. Let the agent create reviewable drafts. Add source references, statuses, expiry, and an audit record.

Week 4: automate one narrow side effect. Lowest-risk approved action only. Validate exact inputs, add idempotency, measure failures as carefully as successes.

At the end, the question is not whether the agent looked clever. It is whether staff trust the queue enough to use it, whether corrections are falling, and whether every side effect can be explained afterwards.

The boring path is the scalable path

MCP is interesting because it gives agents real capabilities. That means the first design decision should be about control, not tool count.

A draft queue is a useful middle ground: the agent does tedious preparation; people keep authority over irreversible changes. Shadow mode creates evidence before risk. Narrow tools and durable state make failures diagnosable.

If that workflow becomes reliable, add one capability at a time. If it does not, you learned something without handing an untrusted process the keys to the business.

The best first MCP workflow is rarely an autonomous agent.

It is a well-labelled queue of work a human can understand, approve, reject, and replay.

Source notes

MCP specification: https://modelcontextprotocol.io/specification/2025-11-25
MCP security best practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
MCP tools: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
Ollama tool support: https://ollama.com/blog/tool-support
Related HappyMonkey pieces: local Ollama/MCP fit; n8n + MCP workflows; approval gates

The night four MCP servers started acting like one system

Stephen Phillips — Sun, 19 Jul 2026 16:17:48 +0000

Last weekend I watched an agent workflow do something I had been waiting to see outside a demo.

Hermes needed to hand a detailed review to another coding agent, start a fairly heavy Codex job, avoid overloading the local server, and leave enough evidence for me to check what happened afterwards.

It did not call one giant "run the swarm" function. It used four small MCP services in sequence.

That was the interesting part.

The run

The project was an evidence-first book-writing system. Hermes had reviewed its claim and citation engine and found a list of engineering problems that needed a coding pass.

The trace looked roughly like this:

find the development agent
send the review to its durable mailbox
confirm that the message arrived
create a durable implementation task
request capacity for the Codex workload
start Codex after the lease is admitted
append working and completion events
verify the resulting code and tests

The resource request declared an estimated 2.2 GB of memory and CPU weight 45. Resource Sentinel admitted it under a time-limited lease. Hermes then launched Codex and recorded the process against the same durable task.

The task history later contained submitted, working and completed events, plus artifact references and verification notes. One completion event recorded 18 passing tests, clean lint modes, compile checks and an independent review.

The workflow was imperfect. More edge cases appeared later and reopened the work. That is a feature, not an embarrassment: durable state made it possible to preserve the real history instead of flattening everything into a cheerful "done" message.

Four MCP servers, four jobs

1. Agent Communication MCP

Agent Communication MCP owns agent identities, cards, durable messages, task records, lifecycle events and artifact references.

Hermes used it to find the development agent, deliver the review, verify the mailbox, create the implementation task and record progress.

The review therefore survived beyond one Slack message or model context window. Another agent could retrieve the same instructions later.

2. Resource Sentinel MCP

Resource Sentinel MCP handles local telemetry and admission control.

A workload supplies an estimated memory requirement, CPU priority and lease duration. The server admits it or queues it according to deterministic host policy. Expiring leases prevent abandoned jobs from holding capacity forever.

Resource Sentinel does not run arbitrary shell commands. It decides whether work may start. Hermes and the coding CLI still own execution.

That boundary matters. A resource monitor should not quietly become a remote command runner.

3. Agent Coordination MCP

Agent Coordination MCP is a narrow control plane for discovering installed CLI agents, inspecting file-based project boards and recording assignments.

The project files remain the source of truth. Codex and other CLIs keep their own sandbox and approval behaviour. The MCP layer records intent and ownership rather than pretending every coding agent has an identical lifecycle.

4. Launcher Project Registry

Launcher Project Registry maps project slugs to local paths, ports, URLs, technology stacks, MCP commands and project context.

Its role was smaller in this run, but still useful. It also exposed a real gap: the book project did not yet have a registry slug, so the task fell back to an absolute local path.

That is exactly the kind of weakness an operational trace should reveal.

Why separate servers worked better

The stack worked because no server tried to own the whole workflow.

Each one returned structured state that Hermes could use in the next decision:

agent = communication.find_agent("dev-agent")
message = communication.send_review(agent, findings)

slot = resources.request_execution_slot(
    workload="codex-review-fixes",
    estimated_memory_mb=2200,
    cpu_weight=45,
)

if slot.status == "admitted":
    task = communication.submit_task(agent, instructions)
    process = launch_codex(task)
    communication.append_event(task, "working", process.reference)

That snippet is illustrative rather than a copy of the actual implementation, but the contract shape is the point.

The orchestrator did not need hidden knowledge of every service. It read tool descriptions, called one bounded operation, inspected the result and chose the next tool.

This was not "agent swarm intelligence"

It is tempting to describe any multi-agent trace as spontaneous collaboration. I do not think that helps.

MCP did not make the coding output correct. The agents did not vote their way to truth. The reliable parts were ordinary engineering controls:

durable task and message IDs;
explicit state transitions;
expiring resource leases;
project-owned artifacts;
deterministic tests and lint gates;
independent review that could reopen the work.

The coding agent still needed supervision. A later review found flaws in backup retention and API validation in a related repository. Those findings were fixed, tested and pushed instead of being waved away because an earlier agent had declared success.

Design rules I would reuse

Keep each MCP server narrow

A mailbox server should not edit repositories. A resource server should not execute caller-supplied commands. A registry should resolve project context without becoming a secrets store.

Smaller contracts make failures easier to locate and permissions easier to reason about.

Make state durable before adding more agents

Adding a second model is easy. Preserving task ownership, evidence, artifacts and failure history is harder and more useful.

If a handoff only exists in chat history, it is not much of a handoff.

Treat host capacity as policy

Local agents share memory, CPU, databases and inference services. Starting every available CLI at once can make all of them slower or take down the services they need.

Admission control belongs in the orchestration path, before process launch.

Verification must be able to reverse "done"

A completion event is a claim. Tests, source checks and independent review decide whether that claim holds up.

The system should preserve a clean way to move from completed back to working when new evidence appears.

What comes next

The immediate work is practical:

register projects that still fall back to absolute paths;
make lease renewal and release visible beside task history;
improve recovery for interrupted processes and stale tasks;
put agent, task and resource state in one control-centre view;
keep tightening the policy around what an agent may call complete.

This stack is still early, and the coordination server is explicitly experimental. But it has now handled useful work on a real project with a trace that survived the agents involved.

That is a better milestone than another polished swarm demo.

The original case study, including sanitized screenshots, is on HappyMonkey.ai.

The four projects are open source:

GOSafe: location-based disaster risk intelligence for real places and dates

Stephen Phillips — Sat, 18 Jul 2026 12:13:40 +0000

GOSafe (live at gosafe.happymonkey.ai) is our prototype for location-based disaster risk intelligence. It combines current events, official forecasts, and carefully bounded AI interpretation to answer a practical question: what should I watch around this place during these dates?

Product boundary: the current UI is a prototype with illustrative signals. It is not a live warning service and must not replace official emergency guidance.

The wedge

People plan trips, events, and moves with weather tabs, news tabs, and half-remembered map apps. GOSafe’s first slice is a location/date risk checker covering severe weather, flooding, wildfire/smoke awareness, and seismic/tsunami context — framed as situational awareness, not prediction theatre.

What “bounded AI” means here

Prefer official forecasts and structured feeds where they exist
Use models to interpret and summarise evidence, not invent certainty
Refuse unreliable claims such as precise earthquake prediction
Keep the product honest about prototype vs operational warning systems

How it is built

GOSafe sits in the disaster-intelligence stack as a modern Next.js app with a clear documentation spine (CONTEXT, ADRs, plans, research). Infrastructure pieces include nginx vhosts for the public hostname and process management for the live prototype.

Why we are building in public

Disaster-adjacent products attract hype and liability. Publishing the prototype boundary early is part of the product: show the architecture, show the limits, and iterate with source-backed signals rather than fear marketing.

Live prototype: gosafe.happymonkey.ai

Theme: evidence-first risk awareness for travel and everyday planning.

Originally published on HappyMonkey.ai.

OpenUKPublicDataMCP: one MCP endpoint for useful UK public data

Stephen Phillips — Sat, 18 Jul 2026 12:13:03 +0000

Agents are only as good as the facts they can reach. OpenUKPublicDataMCP is a no-key-first Model Context Protocol server that gives Claude, Hermes, Cursor, and other MCP clients one reliable place to ask common UK public-data questions — with sources attached.

Why public data needs an MCP layer

UK public APIs are powerful and fragmented: postcodes, GOV.UK search, flood monitoring, ONS statistics, carbon intensity, planning applications, Parliament lookups, and more. Each has its own quirks, pagination, and auth story. Agents should not re-learn that glue in every chat session.

Design principles

No-key-first — core tools work without signup
Source-cited — every tool returns upstream source metadata and retrieval time
Official-first — prefer official UK public-sector APIs; label community sources explicitly
Thin adapters — normalise useful fields, keep upstream payloads available
Optional enrichments — Companies House, OS Places, Met Office, TfL only when keys exist
Read-only by default — no public-sector write operations

What shipped in the MVP

23+ MCP tools, a FastAPI explorer API, and a React map UI under web/. Example capabilities:

Postcode lookup, bank holidays, National Grid carbon intensity
GOV.UK search and data.gov.uk dataset search
Environment Agency flood warnings and areas
ONS datasets/observations and CPIH headline inflation
Planning applications, police street crime near a point
MP / constituency lookups via Parliament APIs
Optional: Met Office forecast, Companies House profile, OS Places, TfL line status

How we use it

Register the stdio MCP server with Hermes (or any MCP client). Agents can plan research, pull a cited answer, and save notes without inventing numbers. A public explorer host also exists for human browsing when the stack is deployed.

Sister project

The same pattern is expanding to the US via OpenUSPublicDataMCP — federal-first, no-key-first access to high-value public sources.

Repo: github.com/HappyMonkeyAI/OpenUKPublicDataMCP

Originally published on HappyMonkey.ai.

miso-tts-docker: local Miso TTS 8B on Windows, Docker Desktop, and RTX 50-series

Stephen Phillips — Sat, 18 Jul 2026 12:12:21 +0000

High-quality local speech is finally useful for agents and demos — if you can get the GPU stack to boot. miso-tts-docker is our unofficial Docker Compose pack for running Miso TTS 8B on NVIDIA GPUs, with a special focus on Windows, Docker Desktop, and RTX 50-series (Blackwell) cards.

Not affiliated with Miso Labs — we wrap upstream inference with GPU-ready containers, Hugging Face caching, and Windows-friendly launchers.

Why we packaged it

Raw research repos rarely survive first contact with Docker Desktop on Windows or brand-new GPU arch flags. Builders hit tokenizer gatekeeping, torchcodec gaps, cache churn, and “works on my Linux box” launch scripts. We wanted a clone-and-run path that still respects the upstream model.

What you get

Docker Compose with NVIDIA GPU passthrough
PyTorch 2.11 + CUDA 12.8 oriented at RTX 5090 / Blackwell (sm_120)
Full bfloat16 Miso path by default (~24 GB VRAM recommended)
Persistent Hugging Face cache volumes
Preflight checks for gated Llama 3.2 tokenizer access
soundfile audio I/O patch so PyTorch 2.11 does not depend on torchcodec
Windows .cmd launchers (no PowerShell execution-policy drama)
Web voice demo: Whisper STT, optional LLM replies, dual TTS backends
Fast mode via Pocket TTS on CPU for low-latency replies
HTTPS via Caddy for mic access from phones/tablets on the LAN

Two speeds of voice

Quality mode runs Miso 8B on GPU for the high-end voice. Fast mode runs Pocket TTS on CPU so demos stay snappy without monopolising VRAM. You can also run both and A/B engines in the web UI.

Honest requirements

≥24 GB VRAM recommended for quality mode
~40 GB disk for first-run downloads
Hugging Face token + accepted Llama 3.2-1B license for the gated tokenizer path

Why it fits HappyMonkey

Voice is becoming a first-class agent interface. Packaging local TTS well is the difference between a LinkedIn demo and something staff can actually use on a desk GPU without a research internship.

Repo: github.com/HappyMonkeyAI/miso-tts-docker

Originally published on HappyMonkey.ai.

Resource Sentinel MCP: stop local AI agents from melting the host

Stephen Phillips — Sat, 18 Jul 2026 12:12:17 +0000

When you run many coding agents, tests, and models on one machine, the failure mode is boring and expensive: OOM kills, thrashing disks, and mysterious hangs. Resource Sentinel MCP is our answer — telemetry plus lease-based admission control that agents can request before heavy work.

The agent host problem

LLM agents are great at starting work and terrible at knowing when the box is already full. Parallel pytest runs, Docker builds, and subagents stacked on a shared laptop or lab server will happily oversubscribe memory and CPU until everything is slow.

We wanted a control plane that is deterministic, not another model guessing mood from vibes.

What Resource Sentinel does

Observes the Linux host (psutil-based telemetry)
Lets workloads request an execution slot with estimated memory and CPU weight
Issues expiring leases (and queues when the host is full)
Persists tickets/leases in SQLite WAL
Exposes FastMCP tools for agents and a read-only HTTP projection for dashboards
Feeds Glitch-compatible telemetry so the “cyber pet” reacts to real host state

How agents use it

Typical pattern for a heavy local job:

Call request_execution_slot with a workload id, estimated MB, and CPU weight
If granted, heartbeating/extend the lease while work runs
Always release on completion so others can proceed

Hermes registers it as MCP server name resource_sentinel (same name under DynamicMCPProxy).

MCP:  http://127.0.0.1:8800/mcp
Health: http://127.0.0.1:8800/healthz
Glitch: http://127.0.0.1:8800/api/resource-state

Boundaries that keep it honest

Policy is pure and fail-closed on invalid requests
It does not execute caller-supplied shell commands
MVP does not enforce cgroups — admission is cooperative via leases
Dashboards consume factual telemetry rather than caller-selected “moods”

Why this is a product story, not just ops glue

Local multi-agent stacks only become practical when the host has a traffic light. Resource Sentinel is that traffic light — small, testable, and agent-native via MCP.

Repo: github.com/HappyMonkeyAI/Resource-Sentinel-MCP

Originally published on HappyMonkey.ai.

PromptOS: an AI-first Linux installer that never builds the same machine twice

Stephen Phillips — Sat, 18 Jul 2026 12:11:29 +0000

Most installers ship a fixed menu of packages. PromptOS is different: a minimal live bootstrap that asks high-level questions, talks to your LLM provider, and generates a hardware-aware installation blueprint on the fly.

The problem with static install media

Traditional distro ISOs are frozen in time. Drivers lag, desktop profiles age, and “recommended packages” become a one-size-fits-none compromise. Maintaining a full custom distro is worse: you inherit package churn, security patches, and endless edge cases.

PromptOS keeps the maintenance burden where it belongs — upstream package managers and the models that already track modern stacks — while the installer itself stays small and focused.

What we built

TUI wizard in Go + Bubble Tea for a static binary on a tiny live environment
Pluggable LLM client for OpenAI, Anthropic, Gemini, or local Ollama
Structured JSON blueprints validated before execution
Executor path for partitioning, chroot bootstrap (archinstall / debootstrap / pacstrap), and config drops
Closed-action install triage, bounded auto-heal, boot-time rescue, and explicit disk-wipe confirmation
CI that matters: GitHub Actions builds the real image and boots it in QEMU through GRUB into OpenRC

How the flow feels

Boot the minimal live image
Pick a provider and enter your key
Answer preference questions in a conversational wizard
The model scans hardware context and drafts a blueprint
The executor applies the plan; if boot fails, AI triage has a rescue path

What it is not

PromptOS is not a full distro, custom kernel, or package repository. It is an intelligent orchestrator. Optional “AI desktop profile” ideas stay later-phase design work; the present focus is a trustworthy installer spine and guest readiness verification.

Why it matters for builders

If you care about local-first AI desktops, self-healing recovery, and reproducible-but-personal machines, the interesting product is not another ISO flavour. It is a bootstrap that can reason about your hardware and intent without trapping you in forever-forked packages.

Repo: github.com/HappyMonkeyAI/prompt-os

Want more build-in-public notes? Follow the series on happymonkey.ai and the org at HappyMonkeyAI.

Originally published on HappyMonkey.ai.

You've Never Sent a Single Word to an AI. Here's What Actually Happens.

Stephen Phillips — Wed, 08 Jul 2026 11:39:39 +0000

You've never sent a single word to an AI.

Every time you hit send on ChatGPT, Claude, or Gemini, your words get shredded before the model ever sees them. The process is called tokenization. Once you understand it, you'll never think about AI the same way again.

What is a token?

A token is the actual unit your AI reads — not a word, not a sentence. Sometimes it's a whole word. Sometimes just a fragment.

"ChatGPT" is 2 tokens.
"Unbelievable" is 3 ("un", "believ", "able").
A single emoji can cost 3 tokens.

Rough rule: 1 token ≈ 4 characters ≈ 0.75 words.

This is what your message actually looks like to an AI. Not words. Colored chunks of subwords.

Why does this matter?

The model never sees language. It sees numbers. Every token gets converted into a vector — a list of hundreds of values that places it in mathematical space.

"King" and "Queen" sit close together in that space. "King" and "pizza" are far apart. The model understands meaning the same way a map understands geography — through distances, not definitions.

This is how AI understands the word "Queen". Not by reading it. By knowing where it sits relative to everything else.

The Strawberry Problem

Ask any LLM how many R's are in "strawberry." Most get it wrong.

Not because it's stupid — because it never sees the full word. It sees "straw" and "berry" as two separate tokens and tries to count letters inside chunks it can't see into.

This is the gap between what AI feels like and what it actually is.

"Straw" + "berry". Two tokens. This is why it can't count the R's.

What changed in 2026?

Tokens aren't just text anymore.

Every major model (GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro…) now handles a million tokens in a single conversation. Images cost tokens. Audio costs tokens. Video costs tokens. Your entire prompt — text, files, screenshots — becomes one long river of numbers the model processes simultaneously.

The one thing to remember

Your prompt is not a command. It's a statistical context — a sequence of numbers that nudges the model toward the most probable next output.

Better context = better predictions. That's the whole game.

How does the AI actually build its token vocabulary?

This is the part nobody explains and everyone should know.

The algorithm behind almost every major AI model (GPT, Claude, Llama, Mistral) is called Byte Pair Encoding, or BPE. It was originally invented in 1994 as a data compression algorithm. OpenAI repurposed it for AI in 2019.

Nobody designed it for language. It just happened to work extraordinarily well.

Here's how BPE actually works (in plain English):

Start with every single character in the alphabet. "h", "e", "l", "l", "o" — each is its own token.
Now scan through billions of words and find the two characters that appear next to each other most frequently. Merge them into a single token.
Repeat. Over and over. Thousands of times.

The result is a vocabulary of subword units — chunks that are bigger than single characters but smaller than full words — that perfectly balances handling rare words and common ones simultaneously.

By the end, your vocabulary might look like:

"ing" is one token (because it appears everywhere)
"un" is one token (prefix of thousands of words)
"2026" is one token (appears enough to earn its own slot)
"xylophone" gets split (rare enough that it never earned a merge)

The final vocabulary of most modern LLMs sits between 32,000 and 128,000 tokens. GPT-4o uses around 100,000.

Every prompt you send gets mapped into this fixed vocabulary and nothing outside it can exist.

This is how AI builds its vocabulary. Not by learning words. By learning which letter combinations appear together most often and merging them.

The hidden bias nobody talks about

Here's something that will make you genuinely uncomfortable.

The training data for most LLMs is heavily skewed toward English. Llama 2, for example, was trained on 89.7% English content.

This means the tokenizer learned English patterns extremely well and everything else poorly.

The result is a hidden inequality baked into every AI interaction:

Processing the same sentence in German or Italian costs about 50% more tokens than in English.
In languages like Burmese or Tibetan, the same text can cost up to 15 times more tokens than the equivalent in English.

Why does this matter?

Because tokens = cost. Tokens = speed. Tokens = how much of your context window gets used up.

If you're using AI in Hindi, Tamil, Arabic, or any non-English language, you are paying more, getting slower responses, and fitting less into each conversation.

Not because the AI is worse. Because the tokenizer was never built with your language in mind.

A developer described this perfectly: "My agent works great in French or English. But if a user asks in Darija, it crashes in quality and becomes unusable."

That's not a bug. That's tokenization.

This is one of the most underreported fairness issues in all of AI right now.

Tokens are no longer just text

This is where 2026 changes everything.

Tokens aren't just words anymore. Every major frontier model now processes images, audio, and video as tokens too.

An image tile costs tokens.
A second of audio costs tokens.
A video frame costs tokens.

What this means in practice:

When you send Claude a screenshot, it doesn't "see" it the way you do. It converts the image into a grid of tiles, encodes each tile into numerical vectors, and feeds those vectors into the same token stream as your text.

Your image. Your voice note. Your PDF. Your video. All of it — one long river of numbers. Processed the same way.

The model has no concept of "this is a picture" versus "this is a sentence." It's all just tokens in a sequence.

This is what people mean when they say AI is becoming truly multimodal. It's not that the model learned to see. It's that vision got tokenized.

Text. Image. Audio. Video. It all becomes the same thing before the model sees it.

Tokens.

What this means for how you use AI (starting today)

Understanding tokenization isn't just academic. It directly changes how you should prompt.

Front-load your important information

The model processes tokens left to right. The beginning of your prompt carries the most weight. Put your most critical instructions first — not buried in paragraph three.
Be concise — you're paying per token

Every word you type is tokens. Every word the model generates is tokens. Verbose prompts with filler phrases waste your context window and cost more on paid APIs. Trim everything that doesn't add meaning.
If you're coding, name things clearly

Code files often exceed the token limit of a single embedding and they have to be chunked. Variable names and function names become individual tokens. Clear, common naming patterns tokenize more efficiently than cryptic abbreviations. "getUserData" tokenizes better than "gtUsrDt."
Switch to English for complex reasoning tasks

This is uncomfortable but true. For tasks requiring deep multi-step reasoning, especially on smaller models, English prompts will outperform non-English prompts because the tokenizer was trained primarily on English. On frontier models this gap is shrinking. On smaller local models, it's still significant.
Don't trust AI with character-level tasks

Spelling backwards. Counting specific letters. Rhyming on a specific syllable. Anagrams. These all require character-level processing that tokenization makes structurally difficult. Use AI for meaning-level tasks. Use code for character-level tasks.

The future of tokenization

Tokenization is not a solved problem. It's actively being reinvented right now.

Researchers are exploring byte-level transformer models that process raw bytes instead of subword tokens entirely. This would mean no vocabulary, no BPE merges, no tokenization bias against non-English languages. Every byte is treated equally.

The tradeoff is sequence length. Bytes are much smaller than subwords, so the same text becomes a much longer sequence, which is expensive computationally.

Other researchers are working on multilingual tokenizers with "language plasticity" — the ability to adapt post-training to new languages without retraining the entire model from scratch.

The goal is simple: an AI that processes every language on earth with equal efficiency, equal cost, and equal quality.

We're not there yet. But tokenization is exactly where that battle is being fought.

Takeaway

Every time you type a message to an AI, a silent, high-speed assembly line starts moving.

Your words get shredded.

Assigned numbers.

Converted into vectors.

Fed into a model that has never read a single word in its life.

And somehow on the other side it answers like it understood everything.

That gap between what's actually happening and what it feels like is the most fascinating thing in technology right now.

Source: Adapted from the excellent thread by Shiny (@Oishaaniii) on X. Original post contains additional visuals and examples.

Stop letting AI agents click the expensive buttons

Stephen Phillips — Sun, 05 Jul 2026 11:04:58 +0000

A small business does not usually need a fully autonomous AI employee.

It needs something less glamorous and much more useful: an agent that can prepare the work, explain its reasoning, show the exact action it wants to take, and then stop before it does anything expensive, public, or hard to undo.

That sounds conservative until you watch an agent connected to real tools. Reading a calendar is harmless. Drafting a reply is useful. Sending that reply to a customer is different. Looking up an invoice is helpful. Issuing a refund, changing a price, publishing a blog post, deleting a record, or promising a delivery date is where the risk changes shape.

This is the line small teams should design around.

The current agent conversation is finally moving past "can it call tools?" and toward "which tools should it be allowed to call without a person?" MCP gives us a common way to expose tools and resources to AI clients. n8n and similar workflow tools give us the plumbing to pause, route, approve, and log decisions. The missing piece is a simple operating model a business owner can understand.

I use this one: let the agent drive the forklift, but keep a human hand on the keys to the warehouse door.

The approval gate is not a failure mode

Developers sometimes treat human approval as a sign that the automation is incomplete. For small businesses, it is often the feature that makes automation deployable.

An approval gate says:

the agent can do the boring research;
the agent can draft the action;
the agent can collect supporting evidence;
the agent can recommend a next step;
but the final irreversible step needs a human yes.

That is safer, and it is easier to sell internally: owners can trust the agent to prepare three clean options without handing it final authority on day one.

This is why n8n's human-in-the-loop tool-call pattern matters. Its docs describe an AI Agent that pauses when it wants to use a tool with human review enabled, then sends an approval request through a configured channel such as Slack, Telegram, or n8n Chat. That is the right mental model: the approval gate lives around specific tools, not around the whole workflow.

The agent should not need permission to summarize a support ticket. It probably should need permission to close it with a refund.

Sort tools by blast radius

Before connecting an agent to business systems, write down the tools it can call and sort them into four buckets.

1. Read-only tools

These fetch information but do not change anything.

Examples:

search the knowledge base;
read product inventory;
fetch appointment availability;
inspect order status;
retrieve recent invoices;
check website analytics.

These are usually safe to run automatically, assuming access control is correct and private data is handled properly. The main risk is information exposure, not operational damage.

2. Drafting tools

These create something that still needs another step before it affects the outside world.

Examples:

draft a customer email;
create an unpublished CMS post;
prepare an invoice but do not send it;
generate a quote;
fill a CRM note;
suggest a schedule change.

These can often run automatically too, because the output is parked somewhere for review. Drafting is where small businesses get a lot of value quickly. A human still owns the final action, but the blank page disappears.

3. Reversible write tools

These change state, but the change is low value, easy to undo, or visible only internally.

Examples:

tag a lead;
update a task status;
add an internal note;
move a ticket between queues;
create a calendar hold;
enrich a record with public data.

These deserve more thought. Some can be automatic after testing. Others should start with approval until the team sees a few weeks of behaviour. The important part is to know why a tool is allowed to write, what the rollback path is, and who gets notified when it does.

4. Expensive buttons

These are actions that spend money, make promises, expose content publicly, affect legal or financial records, or annoy customers if wrong.

Examples:

send an email or SMS to a customer;
publish a website or social post;
issue a refund;
change a live product price;
delete a customer record;
approve payroll;
submit a tax or compliance document;
place an order with a supplier.

These are the expensive buttons. Put approval gates here first.

MCP needs business permissions, not just technical auth

MCP authorization is important because MCP servers can expose sensitive resources and operations. The official docs focus on securing access to restricted servers and protected resources. That is necessary, but business safety needs one more layer.

A valid user token answers: "is this client allowed to access the server?"

A useful small-business policy also asks:

Is this tool read-only or write-capable?
Can this action be undone?
Is there a money limit?
Is there a customer-visible side effect?
Does this action require a manager, owner, or domain expert?
Should the same person who requested the action be allowed to approve it?

That policy does not have to be complicated. A simple YAML file or database table is enough for many teams:

tools:
  read_order:
    risk: read_only
    approval: never
  draft_refund_email:
    risk: draft
    approval: never
  issue_refund:
    risk: expensive_button
    approval: required
    max_without_owner: 25
  publish_wordpress_post:
    risk: public_action
    approval: required
    approvers: [owner, marketing]

The point is not the format. The point is that your agent runtime, MCP gateway, or workflow orchestrator should know the difference between "look this up" and "do this now."

What an approval request should include

A bad approval request says:

The AI wants to use issue_refund. Approve?

A good approval request gives the human enough context to make the decision in ten seconds:

requested action;
customer or record affected;
amount or business impact;
agent's reason;
evidence it used;
exact payload it will send;
rollback path;
timeout behaviour.

For example:

Refund £18.50 to Order #1842 because the courier marked the item lost and the customer has waited 9 days. Evidence: tracking link, customer message, policy section 4.2. If approved, the refund is sent via Stripe and a confirmation email is drafted. If rejected, the ticket stays open.

That is reviewable. The owner can approve, reject, or edit. The agent has still saved the time: it found the order, checked the policy, wrote the rationale, and assembled the payload.

Start with three gates

If you are adding agents to an existing business workflow, do not start with a giant governance programme. Start with three gates.

Public communication gate — anything that sends or publishes outside the company.
Money gate — refunds, invoices, discounts, purchases, payroll, subscriptions.
Record destruction gate — deletes, merges, irreversible CRM/accounting changes.

Everything else can be evaluated tool by tool.

This works especially well with n8n-style workflows. The agent can run the first 80% of the process, then pause at a human-in-the-loop node or approval-enabled tool. The approval can happen in the channel the business already uses. After approval, the workflow resumes and logs the result.

The practical architecture

A small-business agent stack does not need to be exotic:

MCP servers expose business tools: CRM, CMS, calendar, accounting, documents, email.
A gateway or policy layer tags tools by risk and enforces approval rules.
A workflow engine such as n8n handles routing, waiting, reminders, and notifications.
The agent prepares the action and evidence.
A human approves expensive buttons.
Every decision is logged.

You can make this more advanced later with dynamic tool routing, observability traces, local models, and audit dashboards. But the core pattern is simple: agents prepare; humans approve; workflows execute; logs remember.

Why this is good for adoption

Small businesses are not short of AI demos. They are short of trustworthy systems that fit into messy daily operations.

Approval gates make agents less magical and more usable. They give owners a way to start small without handing over the keys. They also produce training data: every approval, rejection, and edit teaches the team where the agent is reliable and where the policy needs tightening.

That is how automation becomes operational instead of performative.

Do not ask, "Can the agent do the whole job?"

Ask, "Which parts can it do safely, and where should it stop?"

That question is much easier to answer. It is also the question that turns AI agents from a risky experiment into something a small business can actually use.

Source notes

n8n docs: human-in-the-loop tool calls can pause an AI Agent before review-enabled tools and request approval through Slack, Telegram, or n8n Chat.
MCP docs: authorization protects access to sensitive resources and operations exposed by MCP servers.
X trend scan, July 2026: current small-business automation discussion is clustering around agents, MCP, workflow automation, and human oversight for high-stakes actions.

Sources:

Your AI agent needs receipts, not vibes: tracing MCP workflows for small businesses

Stephen Phillips — Sat, 04 Jul 2026 13:32:20 +0000

A small-business AI agent is easy to demo and surprisingly hard to trust.

The demo looks clean: connect the agent to email, invoices, a CRM, maybe a few n8n workflows, then ask it to chase unpaid invoices or triage customer messages. It calls the right tools. It writes a neat summary. Everyone nods.

Then Monday happens.

A customer asks why they got the wrong follow-up. The owner wants to know whether the agent actually checked the CRM before it emailed them. The developer opens a log file and finds prompts, HTTP requests, half-useful timestamps, and no story.

That is the line between an AI automation toy and an AI automation system: can you reconstruct what happened after the agent did something real?

For HappyMonkey-style small-business automation, this is the next practical problem after “can the agent call tools?” MCP gives agents a standard way to connect to external systems. n8n and similar tools give teams a place to run repeatable processes. OpenTelemetry and simple receipt logs give you the missing paper trail.

MCP gives the agent hands

The Model Context Protocol is an open standard for connecting AI apps to external systems: local files, databases, tools, search, workflows, prompts. The docs use a USB-C metaphor. Fine. The useful part is the separation.

Instead of hardcoding every integration into the agent, you expose capabilities through MCP servers. The agent discovers a tool, calls it with structured inputs, and gets structured results back.

That matters because small-business stacks are messy. Accounting in one system. Leads from a website form. Bookings in a calendar. The owner still forwards important emails by hand. If every integration needs bespoke agent code, the project dies under maintenance.

MCP makes tool access more regular. It does not magically make the work safe. Once an agent can touch real systems, you need to know what it touched, why, how long it took, what it cost, and what came back.

Tool access without observability is just a more confident black box.

One practical pattern is a dynamic MCP gateway rather than a static pile of servers. We use DynamicMCPProxy for this: the IDE connects to one proxy, sends project/task context, and the proxy lazily activates relevant MCP servers while keeping the active tool count under control. That reduces tool soup. It also creates a control point for receipts: server activation, tool call, latency, and outcome can all pass through one place.

Workflows give the agent rails

This is where tools like n8n fit. AI workflow automation differs from classic app-to-app glue: the AI layer can interpret, decide, and generate, while the workflow layer still provides structure.

That split is useful. Let the agent decide which business action is needed, but put the actual action behind a workflow with retries, validation, credentials, and predictable side effects.

Examples:

lookup_customer_balance
send_payment_reminder_for_invoice
create_follow_up_task
summarize_new_leads_from_website
draft_wordpress_post_from_source_notes

Each can be an MCP-exposed tool or a workflow behind an MCP server. The agent chooses. The workflow executes.

After a failure, the question is not “did we use MCP?” It is “what exactly happened?”

If an invoice reminder went to the wrong person, you need a trace that answers boring questions quickly:

Which user request started this run?
Which model answered?
Which tools did it call?
What arguments did it pass?
Which workflow ran?
Did the workflow retry?
What did the external API return?
Did a human approve the final action?

The boring questions are the business-critical ones.

Traces beat giant logs

A normal application log says “this thing happened at this time.” Useful, but agent runs are nested. One request might include planning, retrieval, model calls, tool calls, workflow calls, retries, and a final response.

A trace gives you the tree.

OpenTelemetry is already the common language for tracing distributed systems. Its GenAI semantic conventions cover model requests, token usage, and related AI operations. Treat model calls and agent steps as first-class spans rather than random log lines.

The CNCF has also written about Jaeger evolving for AI-agent traces with OpenTelemetry. Agent observability is being pulled into the same operational world as services, queues, databases, and APIs.

For small-business automation you probably do not need a huge observability platform on day one. You do need the shape of the data to be right.

A practical trace might look like:

customer_email_triage run
  model.plan
  mcp.tool.search_customer_by_email
  mcp.tool.get_recent_orders
  workflow.n8n.create_support_ticket
  model.draft_reply
  human.approval.requested
  email.send

Each span should carry just enough metadata:

span name: mcp.tool.get_recent_orders
customer_id: cust_123
workflow_run_id: n8n_456
latency_ms: 820
status: ok
records_returned: 3

Do not log private customer content by default. Log IDs, counts, status, latency, cost, tool names, model names, and approval state. Keep sensitive payloads somewhere controlled, if you keep them at all.

That design choice matters. Teams choose local AI or self-hosted workflows for privacy, cost, or control. Observability should not undo that by spraying customer emails into a third-party logging account.

The minimum viable agent receipt

If you are building this for a client, start smaller than you think.

For every agent run, save a receipt with:

Trigger — user message, cron, webhook, or inbound email
Decision — short reason the agent chose a tool or workflow
Tool calls — name, redacted args, status, duration
Workflow calls — workflow ID, run ID, status, retry count
Model usage — model name, latency, token count or local runtime estimate
Human gate — approved, edited, or blocked
Outcome — what changed in the real world

A JSON file is enough at first. OpenTelemetry spans can come later. Design as if someone will ask “why did the agent do that?” because someone will.

{
  "run_id": "run_2026_07_04_001",
  "trigger": "inbound_customer_email",
  "agent": "support_triage_agent",
  "model": "local-llm-via-ollama",
  "tool_calls": [
    {
      "name": "mcp.tool.search_customer_by_email",
      "status": "ok",
      "duration_ms": 210,
      "redacted_args": { "email_hash": "..." }
    }
  ],
  "workflow_calls": [
    {
      "name": "n8n.create_support_ticket",
      "run_id": "n8n_456",
      "status": "ok"
    }
  ],
  "human_approval": "required_before_send",
  "outcome": "drafted_reply_and_created_ticket"
}

Not glamorous. It is what keeps the owner from losing confidence the first time a workflow behaves oddly.

A concrete gateway example

In our stack, DynamicMCPProxy started as a way to stop MCP tool soup: one proxy, right servers for the current project, active tool list under a sensible budget.

The same gateway is a natural place for receipts. Recent versions record JSONL events for handshakes, server activation, lazy materialisation, and child MCP tool calls — run_id, span_id, event type, caller identity, status, latency, server name, runtime, argument keys.

The security detail that matters is what it does not record. HMAC-authenticated sidecar calls log a caller such as service:hmac, but not the key. Tool arguments are summarised as keys, types, lengths, and hashes rather than raw customer content. Optional OpenTelemetry export can mirror the trace later; local JSONL still works without shipping sensitive payloads to a vendor.

Pattern for most small-business agents: local receipts first, OpenTelemetry when traffic or risk justifies distributed tracing.

What I would instrument first

Do not start by instrumenting every prompt token. Start where support pain or money lives.

Invoices: customer lookup, invoice lookup, payment status, reminder generation, approval, send
Leads: source, dedupe, enrichment, CRM write, notification, follow-up task
WordPress/content: source URLs, summarisation, draft creation, image generation, human review, publish state — especially publish state
Local AI / Ollama: runtime and fallback. If a local model fails and the system falls back to cloud, that should be visible. A silent model switch puts a hole in the privacy story.

The sales angle is reliability, not magic

A lot of small-business AI pitches still sound like magic: “we will automate your operations with agents.” Owners have heard enough of that.

A better pitch is concrete:

“We will automate one repetitive workflow. You will see every tool the agent used, every workflow it triggered, whether a human approved it, and what changed. If something goes wrong, we can replay the receipt.”

Less flashy. More believable.

MCP makes integrations less brittle. Workflow tools make actions repeatable. Observability makes the whole thing accountable.

That combination is what turns a clever prototype into a service you can charge for every month.

Source notes

MCP intro: https://modelcontextprotocol.io/docs/getting-started/intro
OpenTelemetry GenAI semantic conventions: https://opentelemetry.io/docs/specs/semconv/gen-ai/
CNCF / Jaeger on AI-agent traces: https://www.cncf.io/blog/2026/05/26/how-jaeger-is-evolving-to-trace-ai-agents-with-opentelemetry/
n8n AI workflow automation overview: https://blog.n8n.io/best-ai-workflow-automation-tools/
DynamicMCPProxy: https://github.com/HappyMonkeyAI/DynamicMCPProxy

Local AI agents for small businesses: where Ollama and MCP actually fit

Stephen Phillips — Fri, 03 Jul 2026 14:04:58 +0000

Local AI is having another moment because the use case finally makes sense.

A small business does not always need the smartest model in the world. It often needs a private assistant that can read the right files, draft the right response and avoid sending customer data to five different cloud services.

That is where Ollama plus MCP becomes interesting.

Ollama gives you a local model endpoint. The Ollama API docs show the default local base URL as http://localhost:11434/api, with endpoints such as /api/generate. MCP gives the agent a standard way to reach tools, resources and prompts around that model.

The combination is not magic. It is just a sensible architecture.

The basic shape

A local-first business agent stack looks like this:

Ollama runs the model.
MCP servers expose business tools.
A thin agent decides what to read or draft.
Human approval gates anything risky.
Logs record what happened.

For many businesses, that is enough.

You can run it on a spare machine, a Mac mini, a local server, or a small GPU box. The exact hardware depends on the model size and workload, but the point is control. Your customer emails, internal notes and messy spreadsheets can stay on your network.

What should stay local

Not every AI task needs to be local. Some jobs are harmless enough to send to a hosted model. But local is worth considering when the data is sensitive, repetitive or close to day-to-day operations.

Good local candidates:

Customer support triage.
Internal knowledge-base search.
First drafts of replies and proposals.
Summaries of call transcripts.
Invoice and receipt categorisation.
Staff process documentation.
Website content drafts from approved notes.

The model does not need to be perfect. It needs to be useful inside a bounded workflow.

A local model that drafts a reply for review can save time today. A local model that autonomously emails customers needs much more work.

Why MCP matters here

A local model by itself is just text in, text out.

MCP changes the shape of the problem. The official MCP tools spec describes tools that a model can discover and invoke, backed by schemas. Those tools can query databases, call APIs or run computations.

That means your local model can become part of a workflow without every integration becoming custom glue.

For example, a local support agent could have:

A read-only inbox search tool.
A customer lookup tool.
A policy document resource.
A draft reply writer.
A ticket note updater.

That is already useful. The agent reads the customer message, checks the policy, drafts a reply and records a summary. A person still approves the final email.

The privacy advantage is real, but not automatic

Running the model locally helps, but it does not make the whole system private by default.

If your MCP tools call cloud APIs, data still leaves the machine. If your logs capture full customer records and sync to a third-party observability service, data still leaves. If the agent can call a web search tool with private context in the query, data still leaks.

Local-first architecture needs boring rules:

Separate local tools from cloud tools.
Mark tools as read-only or write-capable.
Redact sensitive fields in logs.
Keep customer data out of prompts when it is not needed.
Use draft actions before send actions.
Keep approval on anything external-facing.

The model location is only one part of the privacy story.

A first workflow: local proposal assistant

Imagine a small web agency.

Every new lead asks roughly the same questions: price, timeline, whether WordPress is okay, whether SEO is included, whether the agency can migrate old content.

A local proposal assistant could:

Read the contact-form submission.
Search internal service notes.
Pull a few approved case-study snippets.
Draft a reply.
Draft a proposal outline.
Save both for review.

The agent does not need the ability to send the email. It does not need access to payroll. It does not need all files on disk.

It needs a small set of tools and a clear output.

That is the part people miss when they get excited about local agents. The win is not "my laptop has a CEO now". The win is that a boring admin task becomes 70 percent done before you touch it.

Where hosted models still fit

A local setup can also route harder tasks to hosted models.

For example:

Use Ollama for triage, classification and drafts with sensitive data.
Use a hosted model for public research where no private data is included.
Use a stronger hosted model for final editing after removing customer details.

This hybrid approach is often better than ideological purity. Keep sensitive context local. Use stronger cloud models when the input is safe and the quality gain matters.

The MVP stack

For a small business, I would start with this:

Ollama for a local model endpoint.
A filesystem or document MCP server limited to one folder.
An email or CRM MCP server in read-only mode where possible.
A draft writer tool that saves markdown, not sends messages.
A simple approval step.
A log file with tool calls and outcomes.

Then pick one workflow.

Do not start by connecting every system. Start with the task the business already hates doing every week.

The honest limitation

Local models still make mistakes. They may misunderstand instructions, miss details, or produce confident but wrong drafts. Smaller models can be especially brittle with long context or complex tool use.

That is why local agents work best when the workflow is narrow and the failure mode is cheap.

A bad draft is fine. A bad payment action is not.

Local AI plus MCP is not a replacement for business process design. It is a cheaper, more private way to automate the parts of the process that were already clear.

That is a good thing. Most businesses do not need science fiction. They need the inbox to be less awful on Monday morning.

Source notes used while drafting:

MCP tools specification: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
Ollama API introduction: https://docs.ollama.com/api/introduction
n8n MCP server docs: https://docs.n8n.io/connect/connect-to-n8n-mcp-server
n8n MCP tools reference: https://docs.n8n.io/connect/connect-to-n8n-mcp-server/mcp-server-tools-reference
Pydantic Logfire MCP server guide: https://pydantic.dev/docs/logfire/guides/mcp-server/
X trend scans run 2026-07-03 for: MCP agents small business automation, local AI agents Ollama MCP, AI agent tool soup MCP workflow automation.