Your First 3 AI Agents: A Local Deployment Guide for SMEs (2026)

Most guides on AI agents are written for engineering teams. This one is for the five-person accounting firm, the regional distributor with 40 employees, the consultancy that runs on spreadsheets and email. By the end you will have a plan for three agents, in the order that builds trust, running on a machine you own.

Cloud-first agents create three problems for a small company: every agent loop burns paid tokens, your clients’ data travels to a data centre abroad (GDPR Article 28 means a processing agreement and sub-processor disclosures), and the model or its price can change under you. Running the agents locally with Ollama and the Model Context Protocol (MCP) removes all three.

What you need

A machine. Agent 1 runs on anything with 8 GB of RAM, including a Raspberry Pi 5 (about EUR 80). All three run comfortably on a Mac mini M4 with 16 GB (about EUR 700) or any used mini PC with 16 GB.
Ollama and two models: ollama pull llama3.1:8b (4.9 GB) and, for Agent 3, ollama pull qwen2.5:14b (9 GB).
Node.js 18+ and Python 3.11+ with uv, to run MCP servers.
A Slack incoming webhook, or an email account, for delivery.
Time: 2 to 4 hours for Agent 1, 4 to 8 for Agent 2, 8 to 16 for Agent 3.

No account, no API key, no credit card.

Why local-first for a European SME

The EU AI Act classifies systems by risk. Document summaries, meeting prep and internal search fall in the minimal or limited tier; what remains is being clear about how the tool works and where data goes. With local agents the answer to “where does my data go?” is: nowhere. See our AESIA guide for the checklist.

The economics are simple. A 20-person team asking 50 questions a day costs 121 to 242 USD a month on a frontier cloud model; a Mac mini running the same load costs about 3.25 EUR a month in electricity. The full calculation, with September 2026 prices, is in Cloud vs local: calculate your break-even.

graph TD
    TASK["Business task<br/>(document, email, query)"]
    ORCH["Local orchestrator<br/>(Ollama + MCP)"]
    MODEL["Open-weight model<br/>(Llama 3.1 / Qwen 2.5)"]
    TOOLS["MCP tool servers<br/>(filesystem · sqlite · email · calendar)"]
    HUMAN["Human review<br/>(approval gate)"]
    OUTPUT["Output<br/>(summary · draft · alert)"]
    TASK --> ORCH
    ORCH --> MODEL
    ORCH --> TOOLS
    MODEL -->|"ReAct loop"| TOOLS
    TOOLS -->|"results"| MODEL
    MODEL -->|"draft"| HUMAN
    HUMAN -->|"approved"| OUTPUT
    HUMAN -->|"rejected"| MODEL
    style ORCH fill:#0B1628,color:#FAFAFA
    style MODEL fill:#F5A623,color:#0B1628
    style HUMAN fill:#059669,color:#FAFAFA
    style OUTPUT fill:#059669,color:#FAFAFA

Every arrow stays inside your network. The human approval gate is not optional on a first deployment; it is how the team learns to trust the system before you give it autonomy.

MCP in one paragraph

MCP is the connector between a model and your tools. Without it you write glue code for every model-tool pair; with it, an MCP server exposes tools (functions the agent can call) and resources (data it can read), and any MCP-capable runtime discovers them. Think of it as USB for AI. By early 2026 MCP had passed 97 million installs, with community servers for filesystems, databases, calendars, email, Slack, GitHub and Notion. You will not need to write your own server for these three agents.

Step 1: Agent 1, the daily intelligence digest

What it does. Every weekday at 07:00 it reads 10 to 20 RSS feeds relevant to your sector, summarises the significant items into a short briefing (news, competitor signals, regulatory changes) and posts it to Slack or email.

Why first. It is read-only. It touches no internal system and makes no decision; the worst outcome of a mistake is an odd briefing. Your team reads it daily, notices when it is useful, and starts asking what else the agent could do.

# agents/digest_agent.yaml
agent_id: "digest_agent"
model: "llama3.1:8b"          # fast, good at summarising
schedule: "0 7 * * 1-5"       # weekdays at 07:00
mcp_servers:
  - name: "filesystem"
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data/feeds"]
  - name: "fetch"
    command: "uvx"
    args: ["mcp-server-fetch"]
system_prompt: |
  You are a research analyst for a Spanish SME. Each morning you review
  industry news and produce a structured briefing. Be concise. Flag only
  significant developments. Never speculate.
tools: [read_file, fetch, write_file]
output_destination:
  type: "slack_webhook"
  url: "${SLACK_DIGEST_WEBHOOK}"
quality_threshold: 0.75       # re-run if self-score below 75%

ollama pull llama3.1:8b
ollama serve &                     # stays running
npx -y @modelcontextprotocol/server-filesystem /data/feeds   # test the server starts
uvx mcp-server-fetch                                          # same
python agents/run_agent.py --config agents/digest_agent.yaml

run_agent.py is a small loop (about 80 lines) that reads the YAML, connects to the MCP servers with the MCP Python SDK, and calls Ollama’s /api/chat with the tools. Ask your AI assistant to write it from this config; then wire it to cron or n8n. Expected output: a Markdown file in /output/ and a Slack message. If the model calls no tools, check ollama show llama3.1:8b lists tools under capabilities.

After two weeks your team will notice it. After four they will miss it when it is late. That is your permission to deploy Agent 2.

Step 2: Agent 2, the knowledge-base quality monitor

What it does. Once a week it scans your internal documentation (a shared drive, a Notion export, a Confluence space) and produces the ten articles that most need attention: last modified more than 90 days ago, broken links, no summary, no clear audience.

Why second. Every company has a shared drive where documents go to die, and the cost shows up as slow onboarding and decisions made on stale information. The agent finds the problems; a human still decides what to fix.

Hardware. The same machine, with 4 GB more RAM for the embedding model.

# quality_rubric.py — the agent scores each document against these criteria
QUALITY_CRITERIA = {
    "recency":        {"weight": 0.25, "check": lambda meta: (today - meta["last_modified"]).days <= 90},
    "has_summary":    {"weight": 0.20, "check": "llm"},   # first paragraph states the purpose
    "links_valid":    {"weight": 0.20, "check": "llm"},   # filesystem server resolves internal links
    "audience_clear": {"weight": 0.15, "check": "llm"},   # says who it is for
    "actionable":     {"weight": 0.20, "check": "llm"},   # contains next steps or decisions
}
# Score 0-1 per criterion, weighted average = document score. Flag below 0.65.

This is the first agent with write access, and only to one file: the weekly report. Everything else stays read-only. That boundary is deliberate.

Step 3: Agent 3, the meeting preparation briefing

What it does. Thirty minutes before a meeting it reads the calendar event, lists the attendees, pulls the agenda and the relevant internal documents, optionally adds public context on the participants, and sends a one-page briefing to the organiser.

Why third. It is the most visible agent: the output lands in a manager’s inbox before every important meeting, so mistakes are noticed at once. By now you have weeks of practice writing system prompts for your domain, and the quality bar is higher.

Hardware. The same Mac mini, now running all three. Peak memory during inference is about 6 to 8 GB with the 8B model, more with the 14B.

ollama pull qwen2.5:14b            # better reasoning for this agent
# Calendar access: pick a community Google Calendar server from
# https://github.com/modelcontextprotocol/servers and note its start command.
cat > agents/meeting_prep_agent.yaml << 'EOF'
agent_id: "meeting_prep_agent"
model: "qwen2.5:14b"
trigger: "calendar_event_minus_30min"
mcp_servers:
  - name: "filesystem"
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data/knowledge-base"]
  - name: "calendar"
    command: "<start command of the calendar server>"
    auth: "${GOOGLE_CALENDAR_OAUTH}"
  - name: "fetch"
    command: "uvx"
    args: ["mcp-server-fetch"]
    rate_limit: "10/min"           # be polite to public sites
approval_gate:
  enabled: true
  channel: "slack"
  timeout_minutes: 20              # not approved in 20 min: skip and log
output:
  format: "markdown"
  destination: "slack_dm_to_organiser"
EOF

The approval gate is practical: if the agent misidentifies a key attendee, you do not want that sent automatically. After 20 to 30 correct briefings you have the data to decide whether to relax it.

Step 4: wire the three together

Once all three run, they share infrastructure and reinforce each other. The digest feeds the knowledge-base monitor (do your documents reflect recent market changes?), and the monitor’s report feeds meeting prep (which reads the same knowledge base). The pattern is an event bus: each agent writes its output as a row in a SQLite events table, and the others read the rows they care about. Redis or a small message broker comes later, if ever.

What to measure

Metric	Target	Why
Tasks completed / week	Depends on load	Throughput baseline
Human review rate	< 20% for Agents 1 and 2	Reliability
Human override rate	< 5%	Alignment with team preferences
Cost per task	< EUR 0.01 (local inference)	Confirms the economics
False positive rate	< 10% for quality flags	Agent 2 specific

Review weekly for the first month. By week four you have enough data to tune prompts, adjust thresholds and pick the fourth agent.

Pitfalls we hit running this ourselves

Do not skip the approval gate on Agent 3. It is a feature, not a training wheel.
Do not let two agents write the same file at once. SQLite lock conflicts lose data silently; use WAL mode and a write semaphore.
Budget half a day per agent for prompt tuning. A good system prompt takes three to five iterations.
Set a circuit breaker. Three consecutive low-quality outputs: pause the agent and notify the operator.

Where this fits, and the limits

An 8B model summarises, classifies and drafts well. It is weaker at long multi-step reasoning and specialised knowledge, so keep a cloud key with a spending cap for the small share of tasks that need a frontier model, and route the routine, private volume to the local machine. The natural fourth, fifth and sixth agents are support triage, invoice extraction and competitor tracking; each reuses the same Ollama, MCP and SQLite stack.

Next steps

Workflow layer: n8n + MCP: connect AI agents to your business tools.
Model size: SLM vs LLM: which size for which task.
Funding: Kit Digital and Spanish AI grants.
Reference: MCP documentation and the Ollama model library.

Work with us

We run our own company on this pattern, one person plus a set of local agents on a single workstation, and we deploy it for SMEs in Spain and the rest of Europe. If you want help picking your first three automations, book a 15-minute call or see how we work in consulting.