🔒 Internal — not for external publication. These are field notes on our concrete setup (tooling, working model) for internal Swisscom audiences. The public LinkedIn version lives separately (V4). Before sharing wider: check sensitivity — the contents of the vault are confidential, the method described here is shareable. Verify the figures (McKinsey, Deloitte, Accenture) before broad distribution.
About this series: AI Field Notes
AI Field Notes is a series of short, honest write-ups of what we're learning as MTA works with AI in practice. Not polished case studies, not vendor pitches, not "how to win at AI in five steps" — just field notes: what we tried, what worked, what didn't, and what we'd do differently. Some entries will be conceptual, some deeply hands-on. They have one thing in common: they come from real work, with all the mess that implies.
We're writing them because the most useful things we've heard from others were rarely the success stories — they were the honest accounts of the detours. We'd like to return the favour, internally, while the learning is still fresh.
This is #1: The Business Brain — why the foundation under our AI matters more than the model on top, and how we're building one.
What is MTA?
For context, since these notes will travel beyond our immediate circle: MTA stands for Marketing Technology & Automation — a team within Swisscom's B2B marketing organisation. In short, we're the people connecting marketing, technology and (increasingly) applied AI: building the tooling, automation and agentic workflows that make marketing faster and smarter, and figuring out what "AI-first" actually means in day-to-day marketing work rather than on a slide.
That puts us in a specific spot: close enough to the technology to build real things, and close enough to the business to feel immediately where they break. A lot of these field notes come straight out of that tension.
Why we're writing this down
We keep getting asked the same question. It comes from different directions — a colleague piloting an agent, a leader wondering why the impressive demo never quite made it into production, a team staring at a pile of documents and a model that still sounds confidently wrong. Phrased a dozen ways, it's always the same underlying question:
"Why doesn't our AI actually know what we know?"
Let's be honest up front: we don't think we have the answer. We haven't cracked it, we're not selling a framework, and we're wary of anyone who claims a finished playbook for something this young. What we do have is an approach — one we've been living with long enough, through enough dead ends and rebuilds, that it has started to feel interesting and valuable enough to share.
That distinction matters, so we'll state it plainly. This is not a blueprint. It's a set of field notes: where we are today, what we've tried, what worked, what we got wrong, and what we'd do differently. We're sharing it because we increasingly believe other teams at Swisscom are standing in front of the exact same question — and there's no reason for everyone to walk the same detours in isolation. If even one section here saves another team a month, it was worth writing.
A second reason: the more we worked on this, the more we realised the question isn't really an AI question at all. It's a knowledge question that AI happens to have made urgent. The technology finally made visible a gap that was always there — and that reframing changed how we approach it. This document is our attempt to pass that reframing on.
So read this as an invitation, not an instruction. Take what's useful, challenge what isn't, and — ideally — tell us where we're wrong.
The short version (for those who've seen the public piece)
«We know more than we can tell.» — Michael Polanyi, 1966. Most of the knowledge that makes an organisation work is tacit: it lives in people's heads, in chats, in meetings — not in documents. That is exactly the knowledge our AI agents need most, and exactly what they're missing.
Our thesis in one sentence: the bottleneck in today's enterprise AI is not the model, it's the foundation underneath it. We call that missing substrate the «Business Brain». At the Swiss MarTech Summit I recently attend, Accenture showed the same split we see every day (Lavazza «Brand Brain»)… which is ~20% of a brand is explicitly documented, ~80% stays implicit.
That's the theory. This document is about the how — and honestly, about what we learned along the way.
A note on scope and naming
Two things we want to be precise about.
First, the term. We're deliberately cultivating «Business Brain» as the name for this idea. It's the clearest label we've found for the missing substrate, it travels well, and — yes — we'd like it to stick as our way of framing the problem. We didn't invent the concept (Accenture and others use adjacent terms), but we're happy to own this articulation of it.
Second, the scope — and here we want no misunderstanding. The «Business Brain» is the concept. What actually exists today is one concrete, team-scoped implementation of it, which we currently call the MTA Knowledge Vault. It lives within MTA — it is not a Marketing-wide system, and we're not claiming it as one. Whether and how this scales beyond MTA, across the broader Marketing organisation, is a deliberate open question — a next step to be earned, not a done deal to be announced. We'd rather undersell the footprint and let the approach prove itself.
The setup — concretely
Single source of truth: a versioned Markdown vault
At its core, our Business Brain is an Obsidian vault of Markdown files, versioned in GitLab (internal, code.swisscom.com). Deliberately plain — and deliberately not a new tool that first has to be bought, integrated and maintained.
Why this, and not Confluence/SharePoint:
- Markdown is human- and machine-readable. The same file a person reads in Obsidian is the context an agent receives. No export, no format break.
- Git brings versioning, history and conflict handling out of the box — the three properties that matter (below) are built in, not bolted on.
- Free & portable. Plain text in Git runs anywhere, no vendor lock-in, full data sovereignty — the files live in our own GitLab instance, not in someone else's cloud.
- Obsidian as the editor: fast linking, graph view, local-first. The Git plugin syncs work almost invisibly in the background.
A multi-vault structure
We separate by purpose rather than piling everything into one place, cross-linked via obsidian:// URIs. Three vaults form the stable core:
- knowledge-vault — the centre of gravity: use cases, methodology, research, thinking threads.
- mta.strategy — strategy artefacts for wider audiences.
- mta.dataeng — data-engineering-adjacent content.
Beyond these, additional vaults spin up per larger project or initiative — a dedicated space when a topic gets big enough to warrant its own boundary. So the real picture today is "three core vaults plus a handful of project vaults", and that set grows and shrinks as work does.
Learning — and an honest caveat: the separation emerged after the first sprawl. Early on everything sat in one vault and got messy fast. We don't think we've found the final cut yet. Where exactly the boundaries should run — what deserves its own vault versus a folder, when to split, when to merge back — is still actively part of our exploration. We'd rather keep it fluid and let the structure follow the work than freeze a tidy diagram too early.
The three principles — how they're actually implemented
1. Traceability (provenance). Every piece of information should know where it came from. In practice: source and date travel with the content, and the Git history records, without gaps, who changed what and when — the commit author field is our built-in provenance layer. Learning: this only works if the discipline holds. "Unconfirmed, as of March" is more valuable than a smooth claim with no origin — but it has to actually be captured that way.
2. Contradictions are held, not averaged away. Where five people see an account or a decision differently, that disagreement is the information. Git is made for this: competing versions stand side by side, with author and timestamp. On top of that we flag tentative material explicitly ("half-baked", "draft", "exploring"), so work-in-progress isn't mistaken for a settled position — by humans or by agents.
3. Reconciliation with reality. What we believe about our marketing or our customers gets checked against actual outcomes. What holds up gains weight; what's contradicted is corrected or marked uncertain. Learning: this is the hardest part to sustain — the comfortable default is to file something once and never hold it against reality again.
Governance: humans decide, agents propose
Our most important guardrail: only humans edit the vault. An agent may propose — integrating something into the body of knowledge is a conscious human decision. That sounds like friction, but it's precisely the point: it keeps the substrate clean and prevents AI output from quietly amplifying itself. For an enterprise setting it's also the answer to the governance question that otherwise tends to arrive "later".
Surfacing tacit knowledge: interview agents
The real lever isn't in the tool, it's in the conversation. We pull tacit knowledge from where it lives — people — through structured interviews. Processed transcripts of those conversations flow into the vault and feed exactly the mode that previously didn't scale (the human modes in Nonaka & Takeuchi's SECI model). Learning: quality of questions beats quantity of documents. One good 30-minute interview yields more usable substrate than half a Confluence space.
What we learned (the honest list)
- Discipline > technology. The setup is surprisingly simple. The difficulty isn't the tooling, it's the sticking with it: capture provenance, leave contradictions standing, check against reality — every day.
- Start small, but start right. A single domain that hurts or lends itself to it — a brand topic, a key account, a central offering. Not the whole company at once.
- Speed vs. durability. The fast prototype is tempting. It only becomes durable on a foundation built to the three principles. That trade-off recurs constantly — we now make it deliberately.
- Bigger than we thought. We underestimated the effort at the start. That's not an argument against it — it's an argument for doing it seriously rather than on the side.
Why this matters internally, right now
The tools are suddenly in everyone's hands. Everyone wants to build something — an agent here, an assistant there. Foundation, governance, data base? Later, if at all. That creates a hype-driven groove that feels great — until expectation meets reality. This is exactly where the gap opens between what everyone expects and what can actually be delivered on an unresolved foundation. An impressive prototype is built quickly; making it reliable, governance-compliant and grounded in solid data is a different league.
What we're offering isn't a finished solution — it's a stance: foundation first, then scale. We're sharing our field notes because we believe other teams at Swisscom have the same road ahead of them — and not everyone needs to take the same detours.
Let's compare notes
If your team is working on a similar foundation (or stuck in one): let's talk. That exchange — what works for you, what doesn't — is the fastest way to shorten our collective detours. We're genuinely more interested in the conversation than in being right.
Related: «We know more than we can tell» — V4 (public LinkedIn edition). · Sources: Polanyi (1966); Nonaka & Takeuchi (1995, SECI); Anthropic (Context Engineering); Accenture/Lavazza «Brand Brain», Swiss MarTech Summit 2026, Winterthur.