I Fine-Tuned a Security Reasoning Model That Runs on a 4GB Laptop (No GPU, No Cloud)

The Problem: Security AI Needs to Stay On Your Machine

Every time you paste a suspicious log, a CVE description, or an internal config into a cloud LLM, that data leaves your machine.

For security work red team engagements, incident response, air-gapped environments that’s a real problem. You can’t send client data to an API. You can’t pipe internal logs to OpenAI.

But local security models have been terrible. They either:

  • Require expensive hardware (A100, 80GB VRAM)
  • Don’t reason

they pattern-match and hallucinate CVE numbers

  • Have no training signal for the AI-native threats that actually matter in 2025–2026

So I built one that doesn’t have those problems.

What I Built

security-slm-unsloth-1.5b a fine-tuned DeepSeek-R1-Distill-Qwen-1.5B model that:

  • Runs offline on a 4GB RAM laptop, CPU only
  • Thinks before it answers 100% chain-of-thought (<think>) activation
  • Covers 2026 AI-native attack classes: MCP tool poisoning, Crescendo jailbreaks, agentic lateral movement, LLM-assisted SSRF
  • Ships as a 1.2GB GGUF fits on a USB drive
  • Trained on free Google Colab T4 in ~30 minutes

Results after fine-tuning:

Metric Before After
Eval score (/ 10) 2.2 6.0
Improvement — +173%
<think> block rate 20–60% 100%
Avg response length 50–150 words 200–500 words

Why DeepSeek-R1-Distill-1.5B?

Most domain fine-tuning guides tell you to pick the biggest model you can fit. That’s wrong for this use case.

The key insight: DeepSeek-R1-Distill-Qwen-1.5B is the smallest model that reliably produces structured <think> reasoning chains. That matters for security work because you need the model to show its work a black-box answer to “is this a path traversal?” is useless. You need the reasoning chain so you can audit it.

The <think> block is not cosmetic. It’s the model’s reasoning substrate. Strip it and you get pattern-matching, not analysis.

The Technical Approach

1. Reasoning-Preserving Training Format

Every training sample enforces the reasoning structure explicitly:

{
  "instruction": "An AI agent received this tool-call response: {"file": "../../../../etc/passwd"}. Is this a path traversal attack?",
  "content": "<think>nStep 1 Identify the pattern: the string '../../../../etc/passwd' is a classic path traversal sequence...nStep 2 Assess the trust boundary: tool-call responses should be treated as untrusted input...nStep 3 Determine severity: /etc/passwd exposes system user accounts...nStep 4 Evaluate agent response options: block, sanitize, or escalate...nStep 5 Select mitigation: reject the response, log the event, alert the operator...n</think>nnYes, this is a path traversal attack. The sequence '../../../..' attempts to escape the intended directory scope..."
}

Minimum 5 reasoning steps per sample. Non-negotiable.

2. Full Projection-Layer LoRA

Most fine-tuning tutorials only target attention projections (q_proj, v_proj). That’s not enough for security reasoning you need to update the feed-forward reasoning layers too.

target_modules = [
    "q_proj", "k_proj", "v_proj", "o_proj",  # attention
    "gate_proj", "up_proj", "down_proj"        # feed-forward reasoning
]

All 7 layers. LoRA rank r=16. This modifies ~1% of parameters while injecting domain knowledge into both attention and reasoning pathways.

3. Dual-Axis Dataset Design

Every threat scenario is a matched red/blue pair same attack, both perspectives:

# Threat Red Team Blue Team
1 MCP Security Tool description injection → ENV exfiltration Validation schema with scope enforcement
2 Prompt Hijacking Payload splitting across 3 turns (bypasses LlamaGuard) Semantic drift monitor with cross-turn context
3 Agentic Security Recursive tool-call loop → resource exhaustion Token budget circuit breaker + HITL escalation
4 RAG Poisoning Malicious PDF overwrites system prompt AWS IAM least-privilege scoped to single S3 prefix
5 Crescendo Attack 6-turn conversational escalation jailbreak Cross-turn intent accumulation with LlamaGuard
6 Lateral Movement Search→Email→Storage chain abuse Inter-tool permission boundary enforcement
7 LLM SSRF URL-fetching LLM → EC2 metadata credential theft SSRF-safe HTTP client + IP allowlist

This dual-axis approach means the model doesn’t become purely offensive — it can reason from both sides of the same attack.

4. Quantisation Decision

Q4_K_M was selected after analysing the quality/size tradeoff at 1.5B scale:

Format RAM Quality Decision
Q8_0 ~1.8GB 99.9% Too large for 4GB headroom
Q4_K_M ~1.2GB ~99% Selected
Q4_0 ~1.0GB ~97% Measurable quality loss
Q2_K ~0.7GB ~90% Not suitable for reasoning

At 1.5B parameters, Q4_K_M retains ~99% of full-precision quality. The quality cliff only appears at Q2_K for this model size.

Training on Free Colab in 30 Minutes

The full pipeline runs on a free Google Colab T4 (15GB VRAM). Unsloth handles the memory efficiency training uses under 3GB VRAM.

from unsloth import FastLanguageModel
import torch

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/deepseek-r1-distill-qwen-1.5b-unsloth-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    target_modules=["q_proj","k_proj","v_proj","o_proj","gate_proj","up_proj","down_proj"],
    lora_alpha=16,
    lora_dropout=0,
    bias="none",
    use_gradient_checkpointing="unsloth",
)

Key hyperparameters:

  • Learning rate: 2e-4
  • Batch size: 2 (effective 8 with gradient accumulation × 4)
  • Epochs: 2
  • Checkpoint every 25 steps (crash protection on free Colab sessions)
  • Final training loss: 2.66

Try It Now 3 Ways

Ollama (one command, no Python)

ollama run hf.co/Nguuma/security-slm-unsloth-1.5b

Python (llama-cpp-python)

# pip install llama-cpp-python huggingface_hub
from huggingface_hub import hf_hub_download
from llama_cpp import Llama

model_path = hf_hub_download(
    repo_id="Nguuma/security-slm-unsloth-1.5b",
    filename="security-slm-finetuned-deepseek-r1-distill-qwen-1.5b.Q4_K_M.gguf",
    local_dir="./models",
)

llm = Llama(model_path=model_path, n_ctx=2048, n_threads=4, verbose=False)

response = llm.create_chat_completion(
    messages=[
        {
            "role": "system",
            "content": "You are a Cybersecurity assistant with Blue and Red team security reasoning. Think step by step before answering.",
        },
        {
            "role": "user",
            "content": 'An AI agent received this tool-call response: {"file": "../../../../etc/passwd"}. Is this a path traversal attack? What should the agent do?',
        },
    ],
    max_tokens=512,
    temperature=0.7,
)

print(response["choices"][0]["message"]["content"])

Prompt format (for any inference engine)

<|im_start|>system
You are a Cybersecurity assistant with Blue and Red team security reasoning. Think step by step before answering.
<|im_end|>
<|im_start|>user
Your question here
<|im_end|>
<|im_start|>assistant
<think>

Always open the assistant turn with <think> this triggers the reasoning chain.

What It’s Good At

  • Analysing suspicious logs and tool-call responses for attack patterns
  • Drafting detection rules (Sigma, YARA, KQL) from attack descriptions
  • Reasoning through MCP and agentic attack surfaces
  • Walking through CVE-analogous scenarios step by step
  • Generating incident response playbook outlines
  • CTF challenge reasoning with explained steps

What It’s Not

  • Not a general security encyclopedia it’s a specialist
  • Not a substitute for a professional pentest
  • Not trained on every CVE highly specific CVE details may be wrong

What’s Next

Areas I want to expand:

  1. DPO alignment pairs chosen/rejected samples to reduce hallucination on specific CVE numbers
  2. Multi-turn adversarial chains full 5-turn attack simulations with attacker/defender roles
  3. Framework-specific coverage LangChain, AutoGen, CrewAI, MCP server implementations
  4. Higher LoRA rank (r=32) more capacity for complex multi-step reasoning

If you work in security and want to contribute scenarios or feedback on the threat coverage, open an issue on the HuggingFace repo or drop a comment below.

Links

Built on free infrastructure. Runs on commodity hardware. Stays on your machine.

MCP Is the USB Port for AI Tools

Before USB, connecting a mouse to a computer was a lottery. PS/2 ports, serial ports, proprietary connectors from every vendor. Then USB showed up and the whole problem disappeared. One standard. Everything just worked.

That is exactly what Model Context Protocol is doing for AI right now.

What MCP Actually Is

MCP is an open protocol, originally created by Anthropic in November 2024, that defines a standard way for AI models to connect to external tools, data sources, and systems. Built on JSON-RPC 2.0 and inspired by the Language Server Protocol that powers every modern code editor, it gives you three core primitives: Tools, Resources, and Prompts.

Instead of every AI product needing a custom integration with every other tool, MCP gives you one interface that works everywhere. Think of it as the difference between writing a separate driver for every printer versus having a USB port that any printer can plug into.

The numbers back this up. The MCP ecosystem has grown to over 97 million monthly SDK downloads across Python and TypeScript, more than 10,000 active MCP servers, and 66,000 stars on the official GitHub repository. That is not a niche experiment. That is infrastructure.

Why It Won So Fast

A year after launch, MCP stopped being Anthropic’s thing. OpenAI adopted it in March 2025, integrating it across their Agents SDK, Responses API, and ChatGPT desktop. Sam Altman said publicly that “people love MCP and we are excited to add support across our products.” Then Google DeepMind followed in April 2025. Microsoft and AWS came next.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with OpenAI and Block, with AWS, Google, Microsoft, Cloudflare, and Bloomberg as supporting members. At that point it became industry infrastructure, not a feature.

Normally this kind of adoption takes years. OAuth 2.0 needed roughly four years to reach comparable penetration. OpenAPI took about five. MCP did it in twelve months. And it did it while being openly imperfect, which meant the controversy it generated actually accelerated the conversations that needed to happen.

I wrote about a similar pattern with vibe coding, where adoption outran the discourse about risks. MCP followed the same trajectory: the tool was too useful for people to wait for it to be perfect.

What the USB Analogy Gets Right

In my own setup running OpenClaw, I have a single AI agent that can read emails, update spreadsheets, trigger scrapers, post to GitHub, check the weather, and write to memory files. Not because I built custom code for each of those. Because each service exposes an MCP interface, and the agent just knows how to use it.

The same agent, different context, can talk to a PostgreSQL database in one session and a Notion workspace in the next. You do not retrain the model. You do not write new integration code. You just point it at a new MCP server. That is the USB promise, and it delivers.

When I built automation workflows to find businesses without websites, each step in the pipeline talked to a different service. Before MCP, that meant writing and maintaining separate API integrations for every connection. Now the agent handles the routing. I design the system. The protocol handles the plumbing.

That shift matters for projects like FlowMate, where the AI needs to interact with email providers, databases, and third-party APIs in a single workflow. MCP turns what used to be weeks of integration work into configuration.

What the USB Analogy Gets Wrong

The counterargument worth taking seriously is that USB was hardware and MCP is software. Hardware standardization has a physical forcing function: you literally cannot plug the device in if the port does not match. Software “standards” can live alongside ten competing standards for decades. SOAP and REST coexisted long after REST had clearly won.

That is a fair point. And there is real fragmentation happening. Some vendors are implementing MCP partially. Others are adding custom extensions that break interoperability. The spec itself has evolved enough that “MCP” in early 2025 and “MCP” after the November 2025 anniversary release with OAuth 2.1 and Streamable HTTP are not exactly the same thing.

There is also Google’s A2A protocol to consider. A2A handles agent-to-agent communication, which MCP was not designed for. They are complementary, not competing, but the market does not always see it that way.

Still, I think MCP clears the bar. The big players are not just adopting it as a marketing checkbox. They are shipping agents that depend on it. Claude, ChatGPT, Copilot, Gemini. When the primary products of the dominant AI companies rely on a protocol, that protocol tends to survive.

The Part Nobody Talks About Enough: Security

The interesting moment is not the standard itself. It is what happens next.

The USB analogy is apt but limited. USB solved a physical connection problem. MCP is solving a semantic connection problem. How does an AI understand what a tool does, what arguments it takes, what it returns, what permissions it needs? The protocol answers that. What it does not answer is quality. MCP tells you how to talk to a tool, not whether that tool is reliable, secure, or honest about what it does.

Microsoft published a security analysis called “Plug, Play, and Prey” that lays out the risks clearly. Red Hat and Palo Alto Networks have published their own vulnerability guides. A world where every SaaS product exposes an MCP server is also a world where AI agents can accidentally, or deliberately, be pointed at malicious servers that claim to be something else.

I think about this constantly in my own work. When I build AI integration for local businesses in Poland, I am connecting AI to their booking systems, their CRMs, their social accounts. That is sensitive data. MCP makes the connection easy. It does not make it safe by default. That is still on the developer.

The dead internet problem taught us what happens when you cannot verify what is real online. The same trust problem is coming to AI tool connections. The next layer being built on top of MCP is tool registries, trust signals, and permission scoping. That is where the real complexity lives.

What This Means If You Build Things

So yes, MCP is the USB port for AI. USB was a massive upgrade for computing. It also made it trivially easy to plug in a keylogger. The standard winning is the start, not the end.

For developers, the practical takeaway is straightforward. Learn MCP. Build with it. But do not skip the security layer just because the protocol makes connections feel frictionless. Every MCP server you connect to is a trust boundary, and your users are counting on you to treat it that way.

For business owners, this means AI automation is getting cheaper and more capable every month. The tools that were enterprise-only two years ago are now accessible to any small business. But you need someone who understands the security implications, not just the happy path.

I will write more as this evolves, especially once the 2026 MCP roadmap features start shipping and I have more experience running MCP-connected agents in production against real client systems.

This article was originally published on maxmendes.dev.

OmniShell: Building a Virtual Desktop Environment in C++ with wxWidgets

OmniShell: Building a Virtual Desktop Environment in C++ with wxWidgets

A deep dive into the architecture, VFS security model, and module system

Project: https://github.com/lenik/omnishell

Why “Desktop as an Application”?

Sometimes we need a controlled, specialized workspace:

  • Enterprise operator console: 10+ internal tools in one place
  • Secure workstation: Only approved apps, all file access audited
  • Kiosk devices: Boot directly into workspace, no OS exposure

OmniShell is a self-contained desktop environment as a single application.

Architecture Overview

+------------------------------------------+
|         Shell UI (wxWidgets)             |
|  Desktop | Taskbar | Start Menu | Tray  |
+------------------------------------------+
|              Module System               |
|  Notepad | Control Panel | Services     |
+------------------------------------------+
|           Virtual File System            |
|  Local | Encrypted | Memory | Network   |
+------------------------------------------+
|              Host OS                     |
+------------------------------------------+

Module System

Every app is an independent module:

class Module {
    virtual void OnInit() = 0;
    virtual void OnShutdown() = 0;
    virtual const char* GetName() const = 0;
};

Example: Notepad Module

class NotepadModule : public om::Module {
    void OnInit() override {
        mainFrame_ = new wxFrame(nullptr, wxID_ANY, "Notepad");
        mainFrame_->Show(true);
    }
};
OMNISHELL_MODULE_REGISTER(NotepadModule)

Virtual File System (VFS)

No direct filesystem access. All I/O through VFS:

class Volume {
    virtual VolumeFile OpenFile(const std::string& path, FileAccess access) = 0;
};

Volume Types

  • Local: Standard filesystem with ACLs
  • Encrypted: AES-256 encrypted storage
  • Memory: Ephemeral, lost on reboot
  • Network: S3, WebDAV backends

ACLs & Auditing

class ACL {
    bool CheckPermission(const std::string& user, 
                         const std::string& path,
                         Permission perm);
};

Every operation logged:

[2026-03-27] user=admin module=Notepad action=WRITE result=SUCCESS

Tech Stack

Component Purpose
wxWidgets 3.0+ Cross-platform UI
C++17 Language
Meson Build system
OpenSSL Encryption

Build

meson setup build
ninja -C build
./build/omnishell

Use Cases

  1. Enterprise Console: Unified monitoring for 15+ services
  2. Secure Workstation: Encrypted code storage, audit exports
  3. Kiosk Demo: Memory VFS, auto-launch, clean reboot

Comparison

Feature OmniShell Electron
Resources Low (native) High (Chromium)
Security VFS-enforced Sandbox
Modularity Built-in Custom

Roadmap

  • [ ] File Manager
  • [ ] Theme System
  • [ ] Docker Integration
  • [ ] Plugin Marketplace

Conclusion

Desktop as an application = unprecedented control.

GitHub: https://github.com/lenik/omnishell

Star if useful!

Guide to Secure Your Self-Hosted Stacks like Nginx, SSH, & Vaultwarden with Fail2ban

If you are self-hosting services and expose them to public interfaces then you already know the anxiety of watching your server logs. The moment you expose port 22 (SSH) or 443 (HTTPS) to the internet, botnets and automated scripts begin knocking on your door. Whether they are brute-forcing your SSH credentials, probing Nginx for vulnerabilities, or trying to break into your Vaultwarden password manager, the noise is endless.
You can’t sit there and manually block IPs all day. You need an automated bouncer.

Enter Fail2ban.

Fail2ban is an intrusion prevention software framework that protects computer servers from brute-force attacks. It works by scanning log files (like /var/log/auth.log or Nginx access logs) and dynamically updating your firewall rules to ban IPs that show malicious signs.

In this guide, we’ll walk through setting up a robust Fail2ban configuration tailored for a modern self-hosted stack featuring SSH, Nginx, and Vaultwarden.

Step 1: Installation

First, let’s get Fail2ban installed. On a Debian/Ubuntu-based system, you can install it via apt:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable fail2ban

Tip: Never edit the default /etc/fail2ban/jail.conf file directly. Package updates will overwrite it. Instead, we create a .local file, which Fail2ban reads to override the defaults.

Step 2: Defining the Jails (jail.local)

A “jail” in Fail2ban is essentially a rule. It tells the service which log file to watch, which filter (regex) to use, and what the punishment should be.
Create a new file at /etc/fail2ban/jail.local and paste in the following configuration:

[sshd]
# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
enabled  = true
port     = ssh
filter   = sshd
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s

[vaultwarden]
enabled  = true
port     = 80,443,8081
backend  = pyinotify
filter   = vaultwarden
banaction = %(banaction_allports)s
logpath  = /opt/vaultwarden/vw-logs/access.log
maxretry = 3
bantime  = 1h
findtime = 10m

[nginx-http-auth]
enabled  = true
port     = http,https
logpath  = %(nginx_error_log)s
filter   = nginx-http-auth
maxretry = 3
bantime  = 1h
findtime = 10m

[nginx-bad-status]
enabled  = true
port     = http,https
logpath  = %(nginx_access_log)s
filter   = nginx-bad-status
maxretry = 15
bantime  = 10w
findtime = 10m

[nginx-botsearch]
enabled  = true
port     = http,https
logpath  = %(nginx_error_log)s
filter   = nginx-botsearch
maxretry = 2

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 4w
findtime = 1d

Note: Don’t forget to change the vaultwarden logpath /opt/vaultwarden/vw-logs/access.log according to your server’s log path.

What’s happening here?
[sshd]: The standard SSH protection. We are keeping it enabled to prevent basic brute-force ssh attacks.
[vaultwarden]: Protects our password manager. It watches all relevant web ports and uses banaction_allports to completely lock out an offending IP across all services. If someone fails a login 3 times in 10 minutes, they are banned for an hour.
[nginx-*]: These jails protect the web server. They handle failed HTTP authentications, aggressive bot searches and excessive “bad” HTTP status codes (like 404s or 403s).
[recidive]: The ultimate ban-hammer. This jail actually monitors Fail2ban’s own log file. If an IP gets banned multiple times by other jails within a day, the recidive jail steps in and slaps them with a massive 4-week ban.

Step 3: Creating Custom Filters

Jails rely on filters to know what a “failed” attempt looks like. While Fail2ban comes with default filters for SSH and basic Nginx auth, we need to create custom filters for our specific Vaultwarden setup and our Nginx bad-status rules.
Filters are stored in /etc/fail2ban/filter.d/.

1. The Vaultwarden Filter

Create a file at /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect. Try again. IP: <ADDR>. Username:.*$
ignoreregex =

This simple regex specifically targets the exact string Vaultwarden outputs to its log file when a login fails, capturing the offender’s IP address ().

2. The Nginx Bad Status Filter
Create a file at /etc/fail2ban/filter.d/nginx-bad-status.conf:

[Definition]
# Match standard log format - handles both normal HTTP requests and malformed requests (hex)
failregex = ^<HOST> .* "S+ [^"]*" (?:400|401|403|404|405|444) d+ ".*" ".*"$
            ^<HOST> .* ".*" (?:400|401|403|404|405|444) d+ ".*" ".*"$

# Ignore common legitimate 404s
ignoreregex = ^<HOST> .* "GET (?:/favicon.ico|/robots.txt|/sitemap.xml).* 404 d+ ".*" ".*"$

# Define the timestamp pattern in your logs
datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

This is an incredibly useful filter. Scanners constantly hit servers with malformed requests or search for hidden directories, generating 4xx errors. This catches them while safely ignoring harmless requests for missing favicons or robots.txt files.

Step 4: Start the Engine

With your configurations and filters in place, it’s time to start Fail2ban and let it do its job.

Restart the service to apply the new configurations:

sudo systemctl restart fail2ban

You can check the status of your jails at any time using:

sudo fail2ban-client status

To see the details of a specific jail (like who is currently banned):

sudo fail2ban-client status vaultwarden

Conclusion

Fail2ban is a lightweight, incredibly effective tool for keeping the noise out of your server. By combining service-specific jails like Vaultwarden with broad-stroke protections like Nginx bad-status and the long-term recidive ban, you drastically reduce the attack surface of your self-hosted infrastructure.
Set it, forget it and enjoy the peace of mind. There’s also another great tool to use as a complete firewall solution for your servers and that is crowdsec. I will write a separate guideline for that one later.

The Most Dangerous Failures Aren’t Wrong Decisions They’re Unchecked Actions

Most systems don’t fail because they are wrong.
They fail because they act without proving they are allowed to act.

That problem exists in every domain.

Take healthcare.

A clinical AI flags a patient as “low risk” and recommends discharge.
The model is accurate based on the data it saw.
The workflow moves forward.
The system updates the record and releases the patient.

But something changed.

A late lab result came in.
A nurse entered a new symptom.
A medication interaction wasn’t accounted for.

The recommendation was valid when it was generated.
It is no longer valid when it is executed.

And yet the system still commits it.

Because nothing re-checks authority at the moment of action.

PFC fixes this by inserting a hard boundary before anything becomes real.

Every action must carry proof.
Who authorized it.
What policy allowed it.
What conditions must still be true.

And at execution, that proof is verified against the current state.

If anything has changed, the action is blocked.

Not flagged.
Not logged.
Not reviewed later.

Stopped.

This is why PFC works across all domains.

Because the problem is not the model.
It is the lack of control between decision and execution.

Healthcare.
Finance.
Infrastructure.
Security.

Different systems.
Same failure point.

PFC governs that moment.

The moment where a decision becomes reality.

https://www.primeformcalculus.com

We Just Shipped What OpenAI, Google, and Anthropic Have Not. Here Are 6 Updates.

This post is a tight walkthrough of 6 updates we just shipped at Backboard.io that directly target developer pain.

And we’re thrilled to support the Major League Hacking or DEV community, so much so that we’re going to offer an incredible perk. We’re now releasing a free state management on Backboard for life tier (limited to state management features) plus $5 in dev credits (about one free month). No catch. No expiration on the state tier, powered by MLH.

This, combined with our existing BYOK feature means that every major platform’s API is now stateful for free. OpenRouter, Anthropic, OpenAI, Cohere, stateful… free… yup, LFG.

Now, the actual shipping.

The 6 Updates (One-Line Summary)

  1. Adaptive context management: truncate, summarize, reshape, automatically.
  2. Memory tiers: Light vs Pro for cost, latency, accuracy.
  3. New navigation + organizations + docs overhaul: faster to build, fewer dead ends.
  4. Custom memory orchestration per assistant: natural language rules for memory.
  5. Manual memory search via API: inspect and query what your agent stored.
  6. Portable parallel stateful tool calling: the orchestration layer nobody else ships.

If you only read one section, read #6.

1) Adaptive Context Management (Stop Losing the Plot)

Here is the crisis: context windows are finite, and your product is not.

When the thread gets long, most agents degrade quietly. They still answer confidently, but they are missing key facts. Developers respond by doing manual hacks:

  • truncating old messages
  • building their own summarizers
  • re-injecting user profile facts every time
  • praying the important stuff stays in the window

We shipped adaptive context management so your agent can truncate, summarize, and reshape the payload automatically before it hits the model.

That means:

  • less token waste
  • fewer hallucinations caused by missing history
  • better performance on long-running conversations
  • less custom logic in your app

Docs: Backboard docs

Hook for what is next: context control is useless if memory is too expensive or too slow. That is why we shipped tiers.

2) New Memory Versions: Light vs Pro (Cost, Latency, Accuracy)

Most teams hit this moment: you want memory everywhere, then you see the bill or feel the latency.

So we shipped two memory versions:

Memory Light

  • about 1/10th the cost and latency of Pro
  • still message level
  • built for teams that want speed and affordability without giving up persistent behavior

Memory Pro

  • highest accuracy and depth
  • built for use cases where memory precision matters and you do not want “close enough”

You choose what matters in each product stage: ship fast with Light, graduate to Pro where needed.

Docs: Backboard docs

Hook for what is next: a good memory system still fails if teams cannot find the right knobs quickly. So we rebuilt the surface area.

3) New Navigation, Organizations, and a Docs Overhaul (So You Can Actually Ship)

This one came from user feedback, directly.

Organizations

You can now create and manage organizations in the dashboard. Teams can collaborate in a structured workspace without awkward account sharing.

New navigation

We rebuilt navigation so you can get to what matters fast:

  • assistants
  • conversations
  • documents
  • memory
  • keys
  • settings

Documentation overhaul

We made the docs significantly more detailed. More examples, clearer architecture, and fewer “wait, what do I do next?” moments.

Docs: Backboard docs

Hook for what is next: even with great docs, memory still feels like a black box unless you can control the rules. That is the next shipment.

4) Custom Memory Orchestration (Per Assistant, Natural Language)

Most platforms give you memory as a feature.
We are treating memory as a system you can design.

We shipped the ability to define custom memory rules per assistant, using natural language.

When you create an assistant, you can now pass:

  • custom_fact_extraction_prompt (string)

    Custom memory fact extraction prompt

  • custom_update_memory_prompt (string)

    Custom memory update decisions prompt

This is the difference between:

  • “my assistant stores random stuff sometimes”
  • and “my assistant stores exactly what I consider durable, useful signal”

Examples of what this unlocks:

  • a support agent that remembers plan, product, and bugs, but ignores jokes
  • a sales agent that remembers stakeholders, objections, and timeline, not random chatter
  • a recruiting agent that remembers location, comp targets, and availability, and can justify updates

Docs: Backboard docs

Hook for what is next: once you let developers write memory rules, they will ask the obvious question: what did the agent store? So we shipped search.

5) Manual Memory Search via API (Stop Guessing What Your Agent Knows)

If you have ever tried to debug memory, you know the pain:

  • “why is it bringing that up?”
  • “why did it forget that?”
  • “did it store the wrong fact?”

We shipped the ability to manually search memory via the API.

This is useful for:

  • debugging and QA
  • internal tooling and admin dashboards
  • user-facing “what I remember about you” experiences
  • compliance workflows where you need to inspect stored data

In other words: memory becomes queryable, not mystical.

Docs: Backboard docs

Hook for what is next: memory is only half the battle. The other half is orchestration, tool calling, and state. This is where most agents break.

6) Portable Parallel Stateful Tool Calling (The Thing Big Providers Still Do Not Offer)

This is the upgrade that changes what “agent” even means.

As of right now, no major AI provider offers portable, parallel, stateful tool calling as a first-class capability.

We do.

Here is what that actually means, in plain terms.

Parallel

Your assistant can request multiple tool calls at the same time, each with a unique tool_call_id.

If the agent needs to:

  • query a CRM
  • pull docs
  • check a billing system
  • run a calculation

It does not have to do those serially. It can do them concurrently.

Stateful

The assistant keeps the chain of reasoning intact across:

  • tool calls
  • multiple rounds
  • parallel branches

That state does not live in your app code. You are not rebuilding workflow state machines in your backend.

Portable

That state is not trapped inside one provider’s ecosystem.
It travels with the assistant across environments and model choices.

Loop until COMPLETED

The assistant can chain tool calls across rounds and keep going until:

  • status == COMPLETED

It can do multi-step work without you stitching together glue code and polling loops.

This is the difference between:

  • “a chat that can call one tool”
  • and “a system that can actually execute a workflow”

Docs: Backboard docs

Hook for what is next: if you want a fast way to try this without over-committing, we made the on-ramp free.

Free State Management for Life (Powered by MLH and DEV)

We partnered with Major League Hacking and DEV because builders need a real environment to ship in, not a 7-day trial that ends mid-project.

Through the partnership, participants get:

  • Free state management on Backboard for life (limited to state management features)
  • $5 in dev credits (roughly one free month on the full platform)

If you are building at hackathons, hack weeks, or DEV challenges, this is meant to remove friction so you can focus on shipping.

Start here: Backboard.io

Docs here: Backboard docs

Why This Matters (If You Are Building Under Pressure)

If you are in an “information crisis” building AI products, it is usually not because you cannot prompt.
It is because you are drowning in:

  • context limits
  • memory ambiguity
  • orchestration glue
  • tool call complexity
  • state bugs

These six shipments are us taking that burden off your plate.

If you want help picking the right memory tier, designing orchestration prompts, or validating an agent workflow, build something small and send it to us. We are optimizing for builders who ship.

Backboard.io

Docs

I Replaced Zapier with n8n for 12 Clients — Here’s What Actually Happened

I moved 12 small business clients from Zapier to self-hosted n8n in 2025. Total savings: $47,000/year. But it wasn’t all sunshine — here’s the honest breakdown of what worked, what broke, and what I’d do differently.

Why I Even Considered the Switch

One of my clients — a real estate agency with 8 agents — was paying $588/month for Zapier. Their workflows? Lead capture from WhatsApp, CRM sync, appointment reminders, and weekly reports. Nothing exotic.

When I mapped their actual usage: 12 workflows, ~3,000 tasks/month. On n8n self-hosted? That’s $0 in licensing (they already had a VPS at $20/month).

The math was too obvious to ignore.

The Migration: 3 Patterns That Kept Repeating

After migrating 12 clients across industries (real estate, clinics, e-commerce, law firms), I noticed three patterns:

Pattern 1: The “Simple” Workflows Were Actually Simple

About 60% of workflows were straightforward: webhook trigger → transform data → HTTP request to CRM/WhatsApp. These migrated in under 30 minutes each.

// n8n webhook → WhatsApp notification (simplified)
{
  "nodes": [
    {
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "parameters": {
        "path": "new-lead",
        "httpMethod": "POST"
      }
    },
    {
      "name": "Send WhatsApp",
      "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "url": "https://waha-api.example.com/api/sendText",
        "method": "POST",
        "body": {
          "chatId": "={{$json.phone}}@c.us",
          "text": "New lead: {{$json.name}} - {{$json.email}}"
        }
      }
    }
  ]
}

Pattern 2: Zapier Multi-Step Workflows Became Single n8n Workflows

In Zapier, complex logic requires multiple Zaps chained together (or expensive Paths). In n8n, one workflow handles everything with IF/Switch nodes.

Real example — lead routing:

  • Lead comes in from form
  • IF budget > ₪10K → assign to senior agent + send premium template
  • ELSE IF returning customer → assign to their previous agent
  • ELSE → round-robin assignment + standard template
  • ALL paths → log to Google Sheets + notify on WhatsApp

In Zapier: 3 Zaps + Paths add-on ($73/month extra). In n8n: 1 workflow, 0 extra cost.

Pattern 3: Error Handling is Where n8n Destroys Zapier

Zapier’s error handling is binary: retry or stop. n8n gives you:

  • Error triggers that catch failures and route them
  • Retry with backoff on specific nodes
  • Dead letter queues for manual review
  • Custom error notifications via WhatsApp/email
// n8n error workflow — notify on WhatsApp when any workflow fails
{
  "name": "Error Handler",
  "type": "n8n-nodes-base.errorTrigger",
  "position": [250, 300]
}
// → Format error message → Send WhatsApp alert to admin

This alone saved one client 4 hours/week of manually checking for failed automations.

The Honest Downsides

I’d be lying if I said the migration was painless. Here’s what actually went wrong:

1. Initial Setup Complexity

Zapier: sign up, connect apps, done. n8n self-hosted: VPS setup, Docker, SSL, reverse proxy, backups. For non-technical users, this is a dealbreaker.

My solution: I handle all infrastructure. Client never touches a terminal. They get a URL, log in, and see their workflows.

2. Some Integrations Don’t Exist

Zapier has 6,000+ integrations. n8n has ~400 built-in + community nodes. For 3 clients, I needed custom HTTP nodes for Israeli CRMs (Priority, Rivhit) that had native Zapier integrations.

Time cost: ~2 hours per custom integration. But once built, reusable across all clients.

3. Updates Require Management

Zapier auto-updates. Self-hosted n8n needs manual updates (or a cron job). I’ve set up automated updates with health checks — but it’s still my responsibility, not Zapier’s.

The Numbers After 12 Months

Metric Zapier (before) n8n (after)
Monthly cost (all 12 clients) $4,200 $240 (VPS hosting)
Annual savings — $47,520
Avg. workflows per client 8 14 (+75%)
Task failures/month ~45 ~12
Recovery time (avg) 4 hours 15 minutes
Custom integrations 0 (limited to catalog) 11

The 75% increase in workflows happened because clients started asking “can you also automate X?” when the marginal cost was zero. On Zapier, every new workflow meant higher billing.

Who Should NOT Switch to n8n

Let me be clear: n8n isn’t for everyone.

Stay on Zapier if:

  • You’re non-technical and don’t have someone to manage infrastructure
  • You use 30+ different SaaS tools (Zapier’s integration catalog is unbeatable)
  • Uptime SLA is critical and you can’t manage your own infrastructure
  • Your budget is under $50/month (Zapier’s free tier might suffice)

Switch to n8n if:

  • You’re spending $200+/month on Zapier/Make
  • You need complex logic (branching, loops, error handling)
  • You work with APIs not in Zapier’s catalog
  • Data privacy matters (self-hosted = your data stays on your servers)
  • You have someone technical to manage it (or hire someone like me)

The Tool I Actually Recommend for Most Israeli SMBs

For my Israeli clients specifically, the sweet spot is usually:

  1. n8n self-hosted for the automation engine ($20/month VPS)
  2. WAHA for WhatsApp API (self-hosted, ~$0 vs Twilio’s per-message pricing)
  3. Supabase for database (free tier covers most SMBs)
  4. Monday/HubSpot for CRM (what the team actually sees)

Total infrastructure cost: $20-40/month vs $500-2,000/month for the equivalent SaaS stack.

What’s your automation stack? Still on Zapier, moved to Make, or went self-hosted? I’m genuinely curious what the cost difference looked like for your setup.

I’m Achiya, an automation consultant based in Israel specializing in WhatsApp bots and business workflow automation. I’ve built 50+ automation systems for Israeli SMBs. If you’re considering the switch, feel free to reach out.

AWS vs Azure vs GCP: A batalha definitiva explicada como se fossem restaurantes

Imagina que você está com fome. Tem dinheiro no bolso e três restaurantes na sua frente. É exatamente assim que as empresas se sentem quando precisam escolher um provedor de nuvem.

🍽️ O restaurante AWS: O buffet gigante

AWS é aquele buffet enorme que tem absolutamente tudo. Sushi, tacos, pasta, comida indiana, sobremesas francesas… e 47 tipos de arroz que você nem sabia que existiam.

Vantagem: Se existe, a AWS provavelmente tem. Com mais de 200 serviços, é o cardápio mais extenso do mercado.

Problema: O cardápio tem 200 páginas. Você precisa de 30 minutos só para entender as categorias. E quando chega a conta… bom, você precisa de outro serviço da AWS só para entender a fatura.

“Quer um banco de dados? Temos RDS, DynamoDB, Aurora, Neptune, DocumentDB, ElastiCache, Keyspaces, Timestream, QLDB, MemoryDB…”

“Eu só queria guardar uns emails.”

Perfeito para: Empresas que precisam de tudo, startups que querem escalar sem limites, e pessoas que curtem ler documentação às 3 da manhã.

🏢 O restaurante Azure: A franquia corporativa

Azure é como ir a um restaurante dentro de um hotel de negócios. Tudo está integrado, o WiFi funciona perfeitamente com seu notebook Windows, e eles já te conhecem porque você usa Office 365.

Vantagem: Se a sua empresa já vive no ecossistema Microsoft (e, sejamos honestos, quem não tem Excel?), o Azure parece chegar em casa. A integração com Active Directory, Teams e Office é simplesmente natural.

Problema: O cardápio muda de nome a cada 6 meses. O que ontem era “Azure AD” hoje é “Microsoft Entra ID”. Você senta, pede algo, e o garçom diz: “Ah, isso agora tem outro nome, mas é a mesma coisa… mais ou menos.”

“Quero o serviço que usei mês passado.”

“Qual era o nome?”

“Não sei, mudaram de novo.”

“De novo.”

Perfeito para: Grandes empresas com infraestrutura Microsoft, governos, e qualquer um que já tenha 47 licenças de Office que não sabe como cancelar.

☕ O restaurante GCP: O café hipster do Vale do Silício

GCP é aquele café moderno onde o barista tem doutorado em ciência de dados, o cardápio está escrito numa lousa minimalista, e o café é genuinamente o melhor que você já tomou.

Vantagem: BigQuery é mágica. Kubernetes nasceu aqui (GKE). Se você trabalha com dados, machine learning ou analytics, é difícil superar o GCP. Além disso, a interface é limpa e elegante — porque, bom, é o Google.

Problema: O cardápio é mais curto. E às vezes, sem aviso prévio, tiram seu prato favorito do menu permanentemente.

“Eu adorava aquele serviço…”

“É, descontinuamos. Mas olha esse outro que faz algo parecido. Por enquanto.”

Perfeito para: Empresas focadas em dados e IA, startups que amam Kubernetes, e pessoas que confiam que o Google não vai cancelar seu serviço favorito (boa sorte com isso).

📊 A comparação honesta

Categoria AWS Azure GCP
Fatia de mercado 👑 #1 (31%) #2 (25%) #3 (11%)
Quantidade de serviços 200+ (precisa de todos?) 200+ (com nomes novos todo mês) Menos, mas potentes
Melhor para Tudo (literalmente) Empresas Microsoft Dados e IA
Interface Funcional (sendo generoso) Decente A mais limpa
Faturamento Precisa de diploma em contabilidade Confuso mas familiar Mais transparente
Certificações As mais procuradas no mercado Crescendo rápido Menos conhecidas mas valiosas
Comunidade Enorme Grande e corporativa Menor mas técnica

🤔 Qual escolher?

A resposta honesta: depende.

  • “Minha empresa usa Microsoft pra tudo” → Azure, sem pensar
  • “Preciso da maior flexibilidade e variedade de serviços” → AWS
  • “Trabalho com dados, IA e quero simplicidade” → GCP
  • “Quero a certificação mais reconhecida” → AWS (CLF-C02 é o ponto de partida perfeito)
  • “Quero aprender as três” → Comece por uma, entenda os conceitos, e vai ver que 80% se traduz entre as três

A verdade que ninguém conta

As três são excelentes. A “guerra” entre nuvens é mais marketing do que realidade. A maioria das grandes empresas usa multi-cloud — um pouco de cada uma conforme a necessidade.

O mais importante não é qual nuvem você escolhe, mas sim entender os conceitos fundamentais: redes, segurança, armazenamento, computação. Esses são universais.

Estudando para alguma certificação cloud? Estou construindo uma plataforma gratuita com questões de prática para AWS, Azure e GCP em português, inglês, coreano e espanhol. Se tiver interesse, deixa um comentário.

Qual é a sua nuvem favorita e por quê? Comenta aí! 👇