Integrate AI using open-source tools

Wire models into the software your business already runs — self-hosted, auditable, and without a new vendor for every workflow. Which tools to pick, and which to skip.

The trap: one vendor per workflow

Here is how most companies end up with an AI mess.

Sales wants AI in the CRM, so they buy the CRM vendor's AI add-on. Support wants AI in the helpdesk, so they buy that add-on. Engineering signs up for a coding agent. Marketing gets a writing tool. Someone in ops finds a browser extension that "summarises everything".

Six months later you have five bills, five admin panels, five privacy policies you did not read, and no single place where anyone can answer a simple question: what did the model see, and what did it do with it?

Each of those tools works. That is not the problem. The problem is that every one of them wants to be the place your data lives, and none of them can see the other four. Your workflows cross tools. Your AI does not.

This guide is about the other way to do it: put the model between the tools you already run, on infrastructure you control, with one set of logs.

What "integrate" actually means

People say "integrate AI" and mean three different things. Be clear about which one you want before you pick anything.

1. A model call inside a tool you already use. A button in your CRM that drafts a follow-up. A field in your ticket tracker that gets auto-summarised. The model does one thing, in one place, on demand. This is the simplest pattern and often the right one. It needs an API key and about a day of work.

2. An automation that connects tools, with a model step in the middle. "When a ticket is created in Linear, send it to a model, get back a priority and a one-line summary, post both to Slack." No judgement calls beyond the model step; the rest is plumbing. This is what no-code automation tools are for.

3. An agent that reads from several tools, decides, and acts. "Look at the backlog, pick the well-specified bugs, fix them, open pull requests." The model is running a loop with tools and making choices along the way. This is the most capable pattern and the one that needs the most guardrails. We wrote a separate guide on it: Custom AI agents that run in the cloud.

Most teams should start with pattern 1 or 2. Pattern 3 is where you go once the first two are running and you can see the logs.

Keep the tools you have

The first decision is what not to replace. Jira, Linear, GitHub, Notion, Slack, your email — these stay. They hold your history, your team knows them, and every one of them has an API. The point of integration is that the model comes to your tools, not the other way round.

If a vendor's pitch is "move your tickets/docs/customers into our platform and then the AI gets smart", that is a migration project wearing an AI badge. Treat it as one.

The open source stack we recommend

We keep a short list of tools we trust, and we keep it short on purpose. Every one of these can be forked, audited, and run on your own servers. Here they are in the order most teams need them.

Automation: Activepieces

The plumbing layer. Triggers, steps, and a model call wherever you need one, across roughly 700 apps. If your workflow can be drawn as a straight line — this happens, then that, then a model does X, then post the result — this is where it lives. No-code means the ops person who owns the workflow can also change it.

Use it for: pattern 2 above. Ticket routing, digest emails, "when X changes, summarise and notify".

Search and knowledge: PipesHub

Enterprise search across your apps, with citations you can check. The open source alternative to Glean. This matters more than it sounds: half of what people want from "AI at work" is find me the thing and tell me where it came from. A model that answers without a source is a liability in a business; one that links to the doc, the ticket, or the thread is useful.

Use it for: the "where is our policy on X" and "what did we decide about Y" questions that currently go to the one person who remembers.

CRM: Twenty

If you are choosing a CRM now, choose one you can host and extend. Twenty is the open source option with a real data model and no per-seat AI tax. Model calls sit next to the record, not in a vendor's black box.

Use it for: pattern 1. Draft the follow-up, summarise the call, enrich the lead — with the prompt in your repo and the logs on your server.

Agents: Open Agents

Our own project. One agent is one markdown file: a name, the tools it may use, whether it is read-only, and plain-English instructions. Run it locally with a dashboard, then deploy each agent as its own isolated endpoint. Tools come through connected accounts (Jira, GitHub, Slack, Gmail, and so on), so an agent acts through the access you gave it and nothing more.

Use it for: pattern 3, once you are ready. The read-only flag strips mutating tools out server-side, which is the difference between "please don't delete things" and "cannot delete things".

Design: Paper

A connected canvas where design and code stay in sync and agents can work alongside the team. Not everyone needs it. If you ship product, it belongs on the list.

That is the whole directory. If a tool is not on it, it is because we have not run it in a real business yet, not because we forgot.

Where the model runs

"Self-hosted" gets used loosely. Be precise: you can self-host the tooling (the automation, the search index, the agent runtime, the logs) without self-hosting the model. Most teams should do exactly that.

Hosted model via API. You call a frontier model from Anthropic, OpenAI, or Google over their API, under a business agreement that says your data is not used for training and is deleted on a schedule. Everything else — what was sent, what came back, what the agent did with it — sits on your infrastructure. This is the right default for nearly everyone. You get the best models, and you keep the audit trail.

Self-hosted open-weight model. You run a model on your own GPUs. Do this when data residency rules leave you no choice, or when volume makes it cheaper, or when you are processing something you would not send anywhere. It costs more in people than in hardware: someone has to keep it running, patched, and evaluated. Be honest about whether you have that someone.

The mistake is doing the second because it sounds more serious, and ending up with a worse model and a new ops burden for a workflow that did not need either.

Which tools to skip

We get asked about a new tool every week. Here is the filter.

Skip anything that wants to be your system of record. If the AI only works once your data lives inside it, you are buying lock-in with an AI feature on top.

Skip anything that cannot show you the prompt. If you cannot see what instructions the model was given, you cannot fix it when it misbehaves, and you cannot explain it to your board.

Skip anything with no logs you can export. Every model call should be a row somewhere you control: input, output, tool actions, cost. If the vendor's answer to "can I export the logs" is a dashboard screenshot, that is a no.

Skip the per-seat AI add-on for every SaaS you own. Ten tools at €20 a seat a month is a large bill for ten disconnected features. One integration layer is cheaper and it can see across the tools.

Skip browser extensions that read everything. Convenient, and they see every page every employee opens. Ask where that goes.

Skip "AI employee" products with no scoping. An agent sold as a person with a job title, no permission model, and access to everything. That is not an employee. That is an incident waiting for a date.

None of these are villains. Some are good products. They are just the wrong shape for a business that wants to keep its data in one place and its options open.

A worked example: ticket triage that runs every week

Here is a workflow we set up often. It uses pattern 2 with a small piece of pattern 3, and it is a good first integration because nobody is harmed when it gets something wrong.

The job. New support tickets land in Linear. Someone spends the first hour of every day reading them, labelling them, and pinging the right engineer.

The wiring.

1. Trigger (Activepieces): a ticket is created in Linear.
2. Model step: send the title and body to a model with a short prompt — classify as bug/feature/question, suggest a priority, write a one-line summary, name the likely owner from a list you provide.
3. Write to a safe place: add the labels and a comment to the ticket. Do not assign, do not close, do not change status. Labels are reversible; assignments cause noise.
4. Tell a human: post the summary to the support channel with the ticket link.
5. Log: the input, output, and cost of every model call go to a table you own.

The review. For the first two weeks, the person who used to do this by hand checks every label. You will find the model over-uses "bug". Adjust the prompt. It is a text file in your repo, so this is a pull request, not a support ticket to a vendor.

The upgrade. Once the labels are right nine times out of ten, let the workflow assign. Once assignment is right, you can consider an agent that drafts the first reply — read-only on everything except a draft.

Total build time: a day. Time saved: an hour a day, every day. That is the shape of a good first integration.

Before you wire anything: the five questions

Answer these in writing before the first API call. They take twenty minutes and they save you the conversation with your security lead later.

1. Where does the data go? Which model provider, under which agreement, with what retention.
2. Who can read the logs? Name the people. Name where the logs live.
3. What is the kill switch? One toggle, one person, one minute. If stopping the workflow takes a meeting, it is not safe to run.
4. What is the cost cap? A per-day limit on model spend, enforced by the tool, not by hoping.
5. Who owns the prompt? A named person, and a repo it lives in.

If you cannot answer one of these, that is your first task, before the integration.

What "auditable" looks like in practice

Auditable is not a feature you buy. It is three habits.

Prompts in version control. Every instruction a model gets is a file in a repo with a history. When someone asks "why did it start doing that in March", you can answer.

Every call logged. Input, output, tool calls, model, cost, timestamp. On your server. Queryable. This is also how you find out which workflows are worth what they cost.

Read-only by default. Anything that reads and writes should have to earn the write. Start it read-only, look at what it would have done, then grant the write when the log says it is safe.

Do those three and you can answer any question your board, your auditor, or your most sceptical engineer asks. Skip them and you are trusting a dashboard.

Do it this week

Pick one workflow. The rule is: frequent, boring, low-stakes. Ticket labelling, meeting-notes-to-action-items, weekly digest of a channel.

Pick one integration point. Usually a trigger in the tool where the work starts.

Wire it with pattern 1 or 2. Write to a reversible place. Log everything. Have the person who used to do it by hand check it for two weeks.

Then come back and pick the next one.

If you would rather have it done faster, the Business audit & AI automation course is exactly this exercise across your whole business: we map how work actually moves, automate the parts that should not need a person, and tell you plainly which parts should. Or tell us what you're stuck on.

Every tool named in this guide is open source and self-hostable. The full list, with stacks and links, is in the open source directory.