For years, many companies have treated SaaS tools as the natural home for their operations.
Projects live in one product. Chat lives in another. Roadmaps live somewhere else. Documents, customer notes, meeting decisions, tasks, and reporting all end up scattered across vendor systems with different permissions, exports, APIs, and data models.
That worked well enough while the main user was a person clicking through a browser. It works less well when the next user is an AI agent trying to understand the current state of the company, update records, compare priorities, prepare a report, or move a workflow forward under review.
Agentic de-siloing is the process of moving important operational data out of closed SaaS silos and into open, structured, reviewable systems that agents can work with directly.
SaaS remains useful. Dependency is the issue. When the operating memory of a company sits inside tools that are hard to inspect, hard to version, hard to query, and hard to connect to , the company has less control over its own work.
At FORMATION, we recently made that tradeoff concrete. We dropped Slack for Matrix. We dropped Asana for a Codex-centered roadmap workflow. The larger pattern is simple: move communication and roadmap data closer to open source and source-controlled systems, then let agents operate on that data with clear rules, audit trails, and human approvals.
Why SaaS silos are becoming a bigger problem
The old SaaS model assumes that the application owns the workflow.
The tool gives you the interface, the data model, the notification logic, the permissions layer, the export options, and the automation surface. You adapt the business around the product. If the product fits well, this can be efficient. If the product only partly fits, the team starts building workarounds.
Those workarounds are familiar. People add custom fields that only one person understands. They paste long context into comments because the data model cannot express what they need. They create boards that become stale because updating them takes too much manual effort. They export CSV files for analysis, then lose the connection between the analysis and the source. They keep the real decision in chat because the project tool feels too rigid.
AI exposes the cost of that fragmentation.
An agent can only help reliably when it can see the right context, understand the structure, make controlled changes, and leave behind a reviewable result. A closed or awkward SaaS system adds friction at every step. The agent may need a brittle API integration. It may only see partial records. It may not understand the team’s conventions. It may be unable to version a change, run checks, or explain what changed in a form the team can review.
Workflow automation inside existing operations needs a better substrate. The data should be readable. The structure should be explicit. Changes should be trackable. Sensitive actions should require human approvals. The system should support audit logs and observability without requiring a large platform program. This is where AI consulting and implementation has to move beyond advice and into operating design.
What we changed
The first visible change was chat.
We moved from Slack to Matrix because we wanted team communication to live in an open protocol that is easier to integrate with agents. Matrix gives us a self-hostable, open source communication layer with real room structure, bot users, and a better foundation for agentic automation. We can connect agents to conversations, create rooms, manage bot identities, and keep more control over the operating surface.
The second change was roadmap work.
We had used Asana for years. It held a lot of project and roadmap memory, but the data lived inside a product interface that was not ideal for the kind of AI operations we now want. We exported the data, enriched it using our YAML method, stored it in Git, and made it available to Codex.
That shifted the roadmap from a SaaS board into a structured operating asset. In practical terms, we replaced Asana with Codex as the place where roadmap work gets queried, organized, reviewed, and improved.
The YAML layer gives each item a clearer shape. A roadmap item can carry fields such as owner, status, area, priority, dependencies, customer relevance, decision notes, risks, and next action. Git gives us version history, diffs, branches, reviews, and rollback. Codex can inspect the files, reorganize them, query across them, prepare summaries, update structures, and propose changes.
We can now ask questions that were awkward before:
- Which roadmap items are blocked by the same dependency?
- What changed since last week?
- Which ideas are still vague and need product judgment?
- Which tasks have no owner?
- Which items connect to current sales conversations or customer needs?
- Which roadmap themes are growing without a clear decision?
We can also reorganize the roadmap without waiting for a vendor feature. If we want a view by customer impact, strategic theme, technical risk, delivery owner, revenue relevance, or implementation stage, the data is already in a form agents can work with.
Why Git changes the
Git is useful here because it makes operational change reviewable.
In a SaaS product, a task change often becomes a quiet mutation inside a database. Someone changes a field, drags a card, edits a description, or deletes a comment. The history may exist somewhere, but it is rarely the main operating surface.
In a Git-based workflow, change becomes explicit. A proposed roadmap cleanup can be shown as a diff. A larger reclassification can happen on a branch. A weekly planning update can be reviewed before it lands. A mistaken edit can be reverted. The structure of the work can evolve over time without losing the trail of how it changed.
That matters for AI implementation.
Agents are good at reading structured files, comparing versions, editing consistent formats, and following repository instructions. They can work inside a controlled environment with clear permissions and review steps. They can create a pull request instead of silently changing the source of truth. They can explain the change in plain language and show the exact lines affected.
This is one reason AI workflows are becoming relevant beyond software engineering. Nobody needs to turn every operator into a developer. More business work should live in systems that are inspectable, scriptable, versioned, and safe for agents to operate on.
Bringing data and LLM processing closer together
Many AI integrations still treat the LLM as an outer layer.
The model sits beside the SaaS stack. It receives copied text, a partial export, or a connector-mediated view of the data. It writes a summary or drafts a response. Then a person has to paste the output back into the system of record.
Agentic de-siloing changes the architecture. The data and the LLM processing move closer together. The model can inspect the source files, use the same structure every time, apply local rules, run narrow checks, and prepare changes in the place where the data already lives.
This reduces manual work and improves team leverage because the agent does not need to reconstruct the operating context from scratch. The context is already encoded in the data model, the file structure, the instructions, and the review process.
The same pattern can apply beyond roadmap work:
- Meeting notes can become structured decisions and follow-ups.
- Sales conversations can become reviewed next actions and account updates.
- Website work can become content and SEO operations.
- Investor updates can become recurring reporting data.
- Support themes can become product signals.
- Security reviews can become tracked risk items with owners.
Each workflow needs its own controls. Some changes can be proposed freely. Some require approval. Some should never be automated. Good AI workflow automation depends on approvals and escalation rules, audit logs, and operational reliability.
The practical lesson
Small teams should avoid trying to replace every SaaS tool at once.
Start with one workflow where the data is valuable, repeated, and trapped. Look for a place where people keep exporting, copying, summarizing, reformatting, or asking the same status questions. Map the process. Define the fields. Move a first version into a structured format. Add human-in-the-loop review. Let an agent help with organization, cleanup, reporting, and controlled updates.
The first win is usually clarity. The team can see the work again.
The second win is flexibility. The same data can support different views without being locked into one vendor’s interface.
The third win is compounding. Every improvement to the structure, instructions, and review process makes the next agentic workflow easier.
For us, moving from Slack to Matrix and from Asana to Codex is part of a wider operating model. We want practical AI systems that connect tools, data, and teams with less manual coordination. We want working software, not slide decks. We want automation systems with enough control that people trust them in daily work.
That is the real promise of agentic de-siloing. It gives the company more ownership over its operating data and gives agents a better place to work.
If your team is sitting on years of roadmap, project, customer, or operations data inside disconnected tools, the next useful step may be a workflow audit . Identify which data should stay in SaaS, which data should move into an open model, and which agentic workflows become possible once the source of truth is easier to inspect, query, and improve. This is a practical entry point for AI consulting in Berlin, especially for small teams that want AI systems integrated into existing tools and data without adding another silo.