27. oktober publiserte Andreessen Horowitz en omfattende og lang artikkel om hvordan KI-agenter endrer hva en virksomhet er. Den er verd tiden: noe av det klareste jeg har lest om hvorfor data, mening og rettigheter må være på plass før KI gir verdi. Argumentet er, nesten punkt for punkt, det samme som ligger til grunn for Forsvarets datasentriske arkitektur (FDSA). FDSA er ett av målbildene som realiserer Forsvarets digitale reguleringsplan (DRP), og konkretiserer DRPs prinsipper for data og arkitektur. Her er hva artikkelen sier, hvor den treffer FDSA, og hva vi kan lære av den.
Dette notatet handler om argumentet i artikkelen, ikke om produktet. Jeg har ingen tilknytning til eller preferanse for Databricks som leverandør, og Forsvaret har ikke tatt stilling til dem. FDSA er teknologinøytralt, og ethvert produkt måles mot de samme kravene: drift i Forsvarets egne datasentre, autonom drift ved brutt samband på tvers av core, fog og edge, åpne formater og nasjonal kryptokontroll. Databricks leveres i dag som en tjeneste hos de store skyleverandørene, og jeg kjenner ikke til en utgave som kan driftes frakoblet på den måten. Det er derfor tankegangen, ikke teknologien, som er interessant her.
Artikkelen handler om Databricks, et selskap a16z har investert i siden 2013, og som nå omsetter for over sju milliarder dollar i året. Men forfatterne bruker selskapet som inngang til et større spørsmål: hva gjør folk på jobb hele dagen når KI-agenter kan utføre det meste av det rutinepregede arbeidet?
Svaret deres bygger på en observasjon som er lett å overse: hva en ansatt kan gjøre, er begrenset av virksomhetens system for sannhet og beslutning, og det igjen er begrenset av databaseteknologien som ligger under. Databricks' historie er fire teknologibølger som hver har løftet det taket: Spark gjorde maskinlæring raskt, lakehouse slo sammen datavarehus og datasjø, lakebase slo sammen operasjonelle og analytiske data på samme lagring, og nå kommer agentene. Tre år siden var hver interaksjon på plattformen menneskelig. I dag kommer flere spørringer fra agenter enn fra mennesker, og agenter starter over 17 millioner databaser daglig.
Den økonomiske rammen er Ronald Coases spørsmål fra 1937 om hvorfor firmaer finnes i det hele tatt, og Herbert Simons observasjon om at et delt register gjør desentralisert handling trygg. Billettselgeren i Boston trengte ikke ringe alle de andre billettselgerne før hun solgte siste sete til Chicago. Hun så i registeret, og når hun solgte, endret registeret seg for alle. Hierarki var det 20. århundrets informasjonsrutingssystem. Agenter tar over rutingen.
Kjernen i artikkelen er Ghodsis begrep «System of Record for Agents», et felles register som hele tiden må svare på fire spørsmål. Figur 1 viser hvordan de fire spørsmålene faller på FDSAs kapabilitetsområder og fundamenter, og hvilket initiativ i Forsvaret som realiserer svaret.
Det mest brukbare tallet i artikkelen hører til spørsmål 2. Databricks' egne tester viser at en agent som får svare med grunnlag i virksomhetens ontologi, går fra omtrent 50 prosent til 84,5 prosent riktige svar. Det er, så vidt jeg kjenner til, det tydeligste kommersielle argumentet for begrepsapparat og ontologi som noen har publisert. Den som lurer på hvorfor FDSA bruker så mye plass på semantikk, kan starte der.
Spørsmål 3 er det som binder sammen flest ting. «Hva er tillatt» er umulig å svare på uten en autoritativ identitet å knytte svaret til. Databricks løser det ved å gi hver agent en egen identitet i Unity Gateway. I Forsvaret er dette identitets- og tilgangsstyring (ICAM), og det er forutsetningen for at attributtbasert tilgang (ABAC) og maskinelt håndhevet regelverk (policy-as-code) i det hele tatt kan virke. Uten en felles identitet har datasentrisk sikkerhet ingen å spørre om hvem som ber om dataene.
Figur 2 setter de fire spørsmålene sammen til én dataflyt, slik den ville sett ut i Forsvaret. Les den fra venstre: ingen får lese før identitetsløsningen og policyhåndhevelsen har svart på hva som er tillatt, data får mening gjennom ontologien før de blir et svar, og den stiplede sløyfen tilbake fra Evaluering er det som gjenstår.
On 27 October, Andreessen Horowitz published a comprehensive, long-form essay on how AI agents change what a firm is. It is worth the time: one of the clearest accounts I have read of why data, meaning and permissions must be in place before AI creates value. The argument is, almost point for point, the same one that underpins the Norwegian Armed Forces' Data-Centric Architecture (FDSA). FDSA is one of the target architectures that realizes the Norwegian Armed Forces' Digital Regulatory Plan (DRP), making the DRP's principles for data and architecture concrete. Here is what the essay says, where it meets FDSA, and what we can learn from it.
This note is about the argument in the essay, not about the product. I have no affiliation with or preference for Databricks as a vendor, and the Norwegian Armed Forces have taken no position on them. FDSA is technology-neutral, and every product is measured against the same requirements: operation in the Armed Forces' own data centres, autonomous operation under broken connectivity across core, fog and edge, open formats, and national control of cryptography. Databricks is delivered today as a service on the major cloud providers, and I am not aware of an edition that can run disconnected in that way. It is the thinking, not the technology, that is of interest here.
The essay is about Databricks, a company a16z has backed since 2013, now past seven billion dollars in annual revenue. But the authors use the company as a way into a bigger question: what do people do at work all day once AI agents can handle most routine work?
Their answer rests on an observation that is easy to miss: what an employee can do is constrained by the organisation's system of record and decision-making, and that in turn is constrained by the database technology underneath. Databricks' story is four technology waves that each raised that ceiling: Spark made machine learning fast, the lakehouse merged the data warehouse and the data lake, the lakebase put operational and analytical data on the same storage, and now come the agents. Three years ago every interaction on the platform was human. Today more queries come from agents than from people, and agents launch over 17 million databases a day.
The economic frame is Ronald Coase's 1937 question of why firms exist at all, and Herbert Simon's observation that a shared record makes decentralised action safe. The ticket agent in Boston did not have to call every other ticket agent before selling the last seat to Chicago. She consulted the record, and when she sold, the record changed for everyone. Hierarchy was the 20th century's information-routing system. Agents are taking over the routing.
The core of the essay is Ghodsi's "System of Record for Agents", a shared record that must continuously answer four questions. Figure 1 shows how the four questions map onto FDSA's capability areas and foundations, and which Norwegian initiative realises each answer.
The most useful number in the essay belongs to question 2. Databricks' own tests show that an agent grounded in the organisation's ontology goes from roughly 50 percent to 84.5 percent correct answers. As far as I know, it is the clearest commercial argument for vocabularies and ontologies anyone has published. Anyone wondering why FDSA spends so much space on semantics can start there.
Question 3 is the one that ties the most together. "What is allowed" cannot be answered without an authoritative identity to attach the answer to. Databricks solves it by giving every agent its own identity in Unity Gateway. In the Norwegian Armed Forces this is identity, credential and access management (ICAM), and it is the precondition for attribute-based access control (ABAC) and machine-enforced policy (policy-as-code) to work at all. Without a common identity, data-centric security has no one to ask who is requesting the data.
Figure 2 assembles the four questions into one data flow, as it would look in the Norwegian Armed Forces. Read it from the left: nobody gets to read before the identity service and the policy enforcement point have answered what is allowed, data gains meaning through the ontology before it becomes an answer, and the dashed loop back from Evaluation is what remains.
FDSA deler arkitekturen inn i ti kapabilitetsområder. Tabellen leses radvis fra venstre: for hvert område står først hva artikkelen beskriver, deretter hvor godt artikkelen dekker området, og til slutt hva det betyr for FDSA. Dekningsgraden sier noe om artikkelen, ikke om hvor langt Forsvaret har kommet.
| # | Kapabilitetsområde i FDSA | ArtikkelenHva artikkelen beskriver | ArtikkelenDekning av området | FDSAHva det betyr for FDSA |
|---|---|---|---|---|
| 1 | Føderert datastyring | Unity Catalog styrer data på tvers av Jack Dorseys Block-selskaper Square, Cash App og TIDAL. OntoRank avgjør algoritmisk hvilken definisjon som er autoritativ, ut fra hvem som laget den, hvor mye den brukes og hvor nylig den ble endret. | Sterk | OntoRank er en algoritmisk variant av fundament 4.2: en sentral autoritet avgjør ved tvil om begrepsbruk. I FDSA er det en myndighet, hos Databricks en rangering. Forskjellen er verdt en diskusjon. |
| 2 | Datasentrisk sikkerhet | Unity Gateway gir hver modell, agent og hvert KI-verktøy en identitet, et budsjett og guardrails, og logger alle handlinger. | Sterk | «Hva er tillatt» er deres ord for ABAC og Zero Trust (2.2 og 2.4). Realiseres i Forsvaret av identitets- og tilgangsstyring for identitet og av FDDP for policy-as-code. Nytt: identitet for agenter, ikke bare for personell, materiell og systemer. Bør inn i kravene til identitetsløsningen. |
| 3 | Dataprodukter | Ikke eksplisitt. Artikkelen snakker om tabeller og databaser. | Svak | Produkt med eier og kontrakt, og FDSAs FAKTISK-kriterier (finnbare, anvendelige, klare, troverdige, interoperable, sikre, koblede), har ingen motpart. Her er FDSA tydeligere enn Databricks. |
| 4 | Datakatalog | Genie Ontology, beskrevet som en kontinuerlig bygget graf over hva organisasjonen vet. | Middels | Deres katalog er en kunnskapsgraf for agenter, ikke en bestillingsdisk for mennesker. Det er dit en datakatalog bør utvikles (7.3). |
| 5 | Datatjenester | Spark, Genie (naturlig språk til spørring og apper), Agent Bricks (utvikleragenter), og evalueringssløyfen «virket det». | Sterk | Eksemplene fra Novo Nordisk og Rivian er fundament 6 i praksis: forskere og analytikere som får svar uten dataingeniør i løypa. Evalueringssløyfen er ikke beskrevet i FDSA. |
| 6 | Dataforvaltning | Genie Ontology og spørsmålet «hva betyr det», med 50 til 84,5 prosent treffsikkerhet. | Sterk | Artikkelens beste argument for 7.1. Egnet for enhver ledergruppe. |
| 7 | Datautveksling | Åpne tabellformater (Delta Lake, Iceberg, Hudi) som gjorde lakehouse mulig. | Middels | Treffer 1.2 og FDSAs tredje suverenitetsforutsetning om åpne formater. Ingen motpart for utveksling mot allierte eller mellom graderingsnivåer. |
| 8 | Datautnyttelse | Hele delen om firmaets form: agenter som informasjonsrutere, «alle blir ledere», færre lag. Eksempelet er Jack Dorseys Block, som vil erstatte mellomledelse med en felles modell av hele virksomheten. | Sterk, men sivil | Deres anvendelsesområde er virksomhetsstyring i et betalingsselskap. Overføres til kommandokjeden med forsiktighet. Ghodsi skiller selv mellom organisasjonskart og informasjonsflyt; det skillet er viktigere i Forsvaret enn hos Block. |
| 9 | Plattform og infrastruktur | Lakehouse (analytisk) og Lakebase (operasjonell) på samme lagring, kalt LTAP. Databaser som kan grenes og kastes som kode. | Sterk | LTAP er nøyaktig FDSAs fjerde scenario, fusjon av operasjonelle og analytiske data uten rørlegging mellom dem. Ett lagringslag under begge er et konkret krav å ta med i det tekniske målbildet som følger FDSA. Prinsippet gjelder uansett hvilket produkt som realiserer det. |
| 10 | Kommunikasjonsinfrastruktur | Ingen. | Ingen | Artikkelen forutsetter alltid-på sky. Degraderte miljøer (DDIL), fog og edge finnes ikke i deres verden, og det er også grunnen til at produktet i seg selv ikke er et svar for Forsvaret. |
Artikkelen bekrefter mye, men den har også tre ting FDSA ikke har ennå. Det er de som gjør notatet verdt å lese, og her går jeg fra å referere til å mene. Dette er mine vurderinger.
FDSA snakker om felles autoritativ identitet for personell, materiell og informasjonssystemer (2.2). Databricks legger til agenter som en fjerde kategori, med egen identitet, eget budsjett og egne grenser. Når en saksbehandler kan starte hundre agenter om dagen, holder ikke én pålogging per ansatt, og det holder heller ikke at agenten «låner» saksbehandlerens identitet. Da vet ingen i ettertid om det var mennesket eller agenten som hentet dataene.
Slik jeg ser det betyr det tre krav til identitets- og tilgangsstyring som bør være på plass før det første agentbaserte verktøyet er i drift: en agent skal ha egen identitet knyttet til den som startet den; en agent skal ha et eksplisitt mandat (hvilke data, hvilke handlinger, hvilket budsjett) som kan uttrykkes som attributter i ABAC; og hver handling skal spores til agentidentiteten, ikke bare til eieren. Det er samme prinsipp som når et materiellsystem har egen identitet i stedet for operatørens.
«Virket det» er ikke et rapporteringskrav, men en del av registeret. Hver gang et menneske korrigerer en agent, skal korreksjonen forbedre neste kjøring, og det lærte skal ligge igjen i virksomhetens eget register, ikke hos modelleverandøren. FDSA har tilbakemelding fra bruker til dataforvalter (5.3), men ikke sløyfen fra utfall tilbake til policy og modell. Jeg mener det er et naturlig neste steg når FDSA konkretiseres i et teknisk målbilde.
Lakebase kopierer bare endringer, så en agent kan lage en isolert gren av en database på sekunder, eksperimentere, og kaste den. Det er det som gjør det trygt å la agenter jobbe mot ekte data. Jeg ville stilt det som krav til plattformlaget: at dataprodukter kan grenes uten å kopiere hele datamengden.
Den delen av artikkelen som bør leses høyt for enhver som lurer på hvorfor Forsvaret insisterer på datasuverenitet, er avsnittet om to banker. Begge leier den samme KI-modellen for kredittbeslutninger. Den første sender inn et spørsmål, får et svar og lagrer beslutningen. Den andre lagrer hvilke fakta som ga svaret, hver menneskelige overstyring, hvilke beslutninger som viste seg riktige, og justerer reglene sine løpende. Et år senere, når en bedre modell kommer, har bare den ene bygget en bedre bank. Hvis den nye modellen arver definisjonene, rettighetene, de vurderte sakene og unntakene, er det et varig fortrinn. Hvis den starter fra samme prompt som alle andre, er det ikke.
FDSA divides the architecture into ten capability areas. Read the table row by row from the left: for each area, first what the essay describes, then how well the essay covers the area, and finally what it means for FDSA. The coverage grade says something about the essay, not about how far the Armed Forces have come.
| # | Capability area in FDSA | The essayWhat the essay describes | The essayCoverage of the area | FDSAWhat it means for FDSA |
|---|---|---|---|---|
| 1 | Federated data governance | Unity Catalog governs data across Jack Dorsey's Block companies Square, Cash App and TIDAL. OntoRank algorithmically decides which definition is authoritative, based on who created it, how widely it is used and how recently it changed. | Strong | OntoRank is an algorithmic variant of foundation 4.2: a central authority decides when terms conflict. In FDSA it is an authority, at Databricks a ranking. The difference is worth a discussion. |
| 2 | Data-centric security | Unity Gateway gives every model, agent and AI tool an identity, a budget and guardrails, and logs every action. | Strong | "What is allowed" is their phrase for ABAC and Zero Trust (2.2 and 2.4). Realised in the Armed Forces by identity and access management for identity and by FDDP for policy-as-code. New: identity for agents, not just for personnel, materiel and systems. Should go into the requirements for the identity service. |
| 3 | Data products | Not explicit. The essay talks about tables and databases. | Weak | A product with an owner and a contract, and FDSA's FAKTISK criteria (findable, usable, clear, trustworthy, interoperable, secure, linked), have no counterpart. Here FDSA is clearer than Databricks. |
| 4 | Data catalogue | Genie Ontology, described as a continuously built graph of what the organisation knows. | Medium | Their catalogue is a knowledge graph for agents, not an ordering desk for people. That is where a data catalogue should be heading (7.3). |
| 5 | Data services | Spark, Genie (natural language to queries and apps), Agent Bricks (developer agents), and the "did it work" evaluation loop. | Strong | The Novo Nordisk and Rivian examples are foundation 6 in practice: scientists and analysts getting answers without a data engineer in the loop. The evaluation loop is not described in FDSA. |
| 6 | Data management | Genie Ontology and the question "what does it mean", with 50 to 84.5 percent accuracy. | Strong | The essay's best argument for 7.1. Suitable for any leadership team. |
| 7 | Data exchange | Open table formats (Delta Lake, Iceberg, Hudi) that made the lakehouse possible. | Medium | Hits 1.2 and FDSA's third sovereignty precondition on open formats. No counterpart for exchange with allies or across classification levels. |
| 8 | Data exploitation | The whole section on the shape of the firm: agents as information routers, "everyone becomes a manager", fewer layers. The example is Jack Dorsey's Block, which wants to replace middle management with a shared model of the whole business. | Strong, but civilian | Their application area is enterprise management in a payments company. Transfer to the chain of command with care. Ghodsi himself separates the org chart from information flow; that distinction matters more in the Armed Forces than at Block. |
| 9 | Platform and infrastructure | Lakehouse (analytical) and Lakebase (operational) on the same storage, called LTAP. Databases that can be branched and discarded like code. | Strong | LTAP is exactly FDSA's fourth scenario, fusing operational and analytical data without plumbing between them. One storage layer under both is a concrete requirement for the technical target architecture that follows FDSA. The principle holds regardless of which product realises it. |
| 10 | Communications infrastructure | None. | None | The essay assumes always-on cloud. Degraded environments (DDIL), fog and edge do not exist in their world, which is also why the product itself is not an answer for the Armed Forces. |
The essay confirms a great deal, but it also has three things FDSA does not have yet. They are what make the note worth reading, and this is where I move from reporting to opinion. These are my own assessments.
FDSA speaks of a common authoritative identity for personnel, materiel and information systems (2.2). Databricks adds agents as a fourth category, with their own identity, budget and limits. When a case officer can launch a hundred agents a day, one login per employee is not enough, and neither is letting the agent "borrow" the officer's identity. Afterwards, nobody knows whether the human or the agent fetched the data.
As I see it, this means three requirements for identity and access management that should be in place before the first agent-based tool goes live: an agent gets its own identity tied to whoever launched it; an agent gets an explicit mandate (which data, which actions, which budget) expressible as ABAC attributes; and every action is traced to the agent identity, not just to its owner. It is the same principle as a materiel system having its own identity rather than the operator's.
"Did it work" is not a reporting requirement but part of the record. Every time a human corrects an agent, the correction should improve the next run, and what was learned should stay in the organisation's own record, not with the model vendor. FDSA has feedback from user to data steward (5.3), but not the loop from outcome back to policy and model. I think it is a natural next step as FDSA is made concrete in a technical target architecture.
Lakebase copies only changes, so an agent can create an isolated branch of a database in seconds, experiment, and throw it away. That is what makes it safe to let agents work against real data. I would make it a requirement on the platform layer: data products can be branched without copying the whole dataset.
The part of the essay that should be read aloud to anyone wondering why the Norwegian Armed Forces insist on data sovereignty is the passage about two banks. Both rent the same AI model for credit decisions. The first sends in a question, gets an answer and stores the decision. The second stores which facts produced the answer, every human override, which decisions turned out right, and adjusts its rules continuously. A year later, when a better model arrives, only one of them has built a better bank. If the new model inherits the definitions, the permissions, the evaluated cases and the exceptions, that is a lasting advantage. If it starts from the same prompt as everyone else, it is not.
Forfatterne kaller dette «det suverene firmaet»: et firma som kan bytte leverandør uten å miste det det har lært. Microsofts Satya Nadella sier noe lignende om «token capital», KI-kapasiteten et selskap bygger og eier selv, og Nvidias Jensen Huang kaller selskapets egne data for gullgruven.
Dette er, med sivil språkdrakt, kjernen i FDSAs første fundament, datasuverenitet, og i Stortingets vedtak 991 og 992 fra 2026 om nasjonal kontroll over data og infrastruktur. FDSA legger til en tredje forutsetning som artikkelen bekrefter indirekte: åpne formater. Lakehouse ble mulig fordi tre selskaper uavhengig av hverandre landet på åpne tabellformater. Proprietære formater gir innlåsing selv innenfor norsk jurisdiksjon.
Eierskap alene er ingen vollgrav, sier forfatterne, men det hindrer at firmaets hukommelse blir fanget i en leverandørs teknologistabel. Fortrinnet oppstår når dataene og KI-en som resonnerer over dem, gjør firmaet bedre raskere enn konkurrentene.
Bytt ut «konkurrentene» med «motstanderen», så har du Forsvarets versjon.
Hvis du bygger noe for Forsvaret i dag, enten innenfra eller som leverandør, er det fire konkrete konsekvenser.
Publiser data som produkt, ikke som skjermbilde. Agentene i artikkelen leser og skriver direkte mot registeret. Et system som bare leverer informasjon gjennom sitt eget brukergrensesnitt, er usynlig for en agent. FDSAs krav om at applikasjoner avgir informasjon av felles verdi gjennom standardiserte grensesnitt (9.1) er det som gjør systemet ditt brukbart i en agentverden.
Knytt dataene til begrepsapparatet. Forskjellen mellom 50 og 84,5 prosent riktige svar er ikke modellen, men om modellen vet hva feltene betyr. Hvert dataprodukt som registreres uten kobling til begreper og ontologi, er et dataprodukt agentene vil misforstå.
Gi agenten sin egen identitet. Ikke la verktøyet ditt kjøre med brukerens pålogging. Knytt det til den felles identitetsløsningen som egen aktør med eget mandat, slik at tilgangen kan styres med attributter og handlingene kan spores. Det er dyrere å bygge om i ettertid enn å gjøre riktig fra start.
Logg hvilke fakta som ga svaret. Opphav og sporbarhet (3.5) er ikke bare et revisjonskrav. Det er råvaren for evalueringssløyfen. Et svar uten spor tilbake til kildene kan ikke læres av.
Artikkelen beskriver et jernbaneselskap som har lagt skinnene, bygget rutetabellen, og nå lar automatiske tog kjøre uten lokfører. I Forsvaret er den digitale reguleringsplanen (DRP) reguleringsplanen for hele området: hva som kan bygges, og hvilke regler som gjelder overalt. FDSA er sporplanen innenfor den: hvilken sporvidde som gjelder, hvor stasjonene ligger, og hvem som eier skinnene og rutetabellen.
Forskjellen er at vi i Forsvaret har planlagt for at skinnene kan bli sprengt, og det har ikke de. De har planlagt for at togene kjører seg selv, og det har ikke vi ennå. Jeg mener begge deler hører hjemme i den samme sporplanen, og at artikkelen er en god grunn til å ta det neste steget nå.
Ben Horowitz og Michael McGuiness: Databricks & the Future of the Firm, a16z.com, 27. oktober 2026.
Digital transformasjon i Forsvaret, forsvaret.no, med målbildet for Forsvarets datasentriske arkitektur (FDSA), Forsvarets skystrategi og Forsvarets digitale reguleringsplan (DRP) som nedlastbare dokumenter. FDSA trådte i kraft 5. oktober 2026.
Innst. 440 S (2025–2026), jf. Prop. 68 S (2025–2026), vedtak 991 og 992.
Alle tall om Databricks er artikkelens egne. Forfatterne er investorer i selskapet; tallene er ikke uavhengig verifisert her. Jeg har ingen tilknytning til Databricks eller a16z. Mappingen mot FDSA og figur 1 til 3 er min tolkning, ikke Forsvarets offisielle lesning.
Notatet er skrevet med Claude fra Anthropic som arbeidsverktøy: lesing og sammenfatning av kildeartikkelen, mapping mot FDSA, oversettelse og teksthjelp. Figur 2 og 3 er tegnet med Archify. Vurderingene, redigeringen og ansvaret for innholdet er mine. Det er for øvrig et lite eksempel på artikkelens eget poeng: verktøyet leverte fart, men det er fagkunnskapen om FDSA som avgjorde hva som ble stående. Den engelske versjonen er en oversettelse av den norske; ved avvik gjelder den norske.
The authors call this "the sovereign firm": a firm that can switch vendors without losing what it has learned. Microsoft's Satya Nadella says something similar about "token capital", the AI capability a company builds and owns itself, and Nvidia's Jensen Huang calls a company's own data its gold mine.
This is, in civilian language, the core of FDSA's first foundation, data sovereignty, and of the Norwegian Parliament's decisions 991 and 992 of 2026 on national control over data and infrastructure. FDSA adds a third precondition the essay confirms indirectly: open formats. The lakehouse became possible because three companies independently landed on open table formats. Proprietary formats lock you in even within Norwegian jurisdiction.
Ownership alone is not a moat, the authors say, but it keeps the firm's memory from being trapped in a vendor's stack. The advantage emerges when the data and the AI that reasons over it make the firm better faster than its competitors.
Replace "competitors" with "adversary", and you have the Armed Forces' version.
If you are building something for the Norwegian Armed Forces today, from inside or as a supplier, there are four concrete consequences.
Publish data as a product, not as a screen. The agents in the essay read and write directly against the record. A system that only delivers information through its own user interface is invisible to an agent. FDSA's requirement that applications expose information of shared value through standardised interfaces (9.1) is what makes your system usable in an agent world.
Tie the data to the vocabulary. The difference between 50 and 84.5 percent correct answers is not the model, but whether the model knows what the fields mean. Every data product registered without a link to concepts and ontology is a data product the agents will misunderstand.
Give the agent its own identity. Do not let your tool run on the user's login. Attach it to the common identity service as its own actor with its own mandate, so access can be governed by attributes and actions can be traced. Retrofitting is more expensive than getting it right from the start.
Log which facts produced the answer. Provenance and lineage (3.5) are not just an audit requirement. They are the raw material of the evaluation loop. An answer with no trace back to its sources cannot be learned from.
The essay describes a railway company that has laid the tracks, built the timetable, and now lets automatic trains run without a driver. In the Norwegian Armed Forces, the Digital Zoning Plan (DRP) is the zoning plan for the whole area: what may be built, and which rules apply everywhere. FDSA is the track plan within it: which gauge applies, where the stations are, and who owns the rails and the timetable.
The difference is that we in the Armed Forces have planned for the tracks being blown up, and they have not. They have planned for the trains driving themselves, and we have not yet. I believe both belong in the same track plan, and that the essay is a good reason to take the next step now.
Ben Horowitz and Michael McGuiness: Databricks & the Future of the Firm, a16z.com, 27 October 2026.
Digital transformation in the Norwegian Armed Forces, forsvaret.no (in Norwegian), with the FDSA target architecture, the Armed Forces' cloud strategy and the Digital Zoning Plan (DRP) as downloadable documents. FDSA entered into force on 5 October 2026.
Recommendation 440 S (2025–2026) to the Storting, cf. Proposition 68 S (2025–2026), decisions 991 and 992.
All figures about Databricks are the essay's own. The authors are investors in the company; the figures have not been independently verified here. I have no affiliation with Databricks or a16z. The mapping to FDSA and figures 1 to 3 are my interpretation, not the Armed Forces' official reading.
This note was written with Claude from Anthropic as a working tool: reading and summarising the source essay, mapping it against FDSA, translation and drafting help. Figures 2 and 3 were drawn with Archify. The assessments, the editing and the responsibility for the content are mine. It is, incidentally, a small example of the essay's own point: the tool delivered speed, but it was the domain knowledge of FDSA that decided what stayed in. This English version is a translation of the Norwegian original; where they differ, the Norwegian text applies.