I remember analyzing Palantir’s business model back in 2019–20 and finding its strategy almost counterintuitive.
I remember analyzing Palantir’s business model back in 2019–20 and finding its strategy almost counterintuitive. At a time when Google and Meta had built some of the most valuable cash machines in history by serving consumers at massive scale, Palantir was doing the opposite: going deep into the enterprise and tackling complex software problems most companies did not want to touch.
That became its edge. Palantir’s land-and-expand model was built on a simple premise: solve hard problems first, embed deeply into the organization, then expand from there.
The forward-deployed engineer became central to that model, and Palantir effectively defined the category.
Over the last four years, I have argued that this role matters because enterprise AI is not primarily a model problem. It is an integration problem. Models have to connect with fragmented data, legacy systems, workflows, governance structures, and humans operating in highly constrained environments.
What has changed is that everyone now wants the enterprise. The AI labs have pivoted toward it, hyperscalers are moving deeper into it, and the enterprise layer has become one of the main battlegrounds of the AI stack. This is the foundation of my Enterprise Alliance thesis and the broader Enterprise AI Coordinate System.
Google is now entering the same arena from the opposite direction. It spent most of its history building consumer-scale search infrastructure. Now it is attempting to repurpose that machinery to solve the enterprise context and integration problem.
Google’s bet is that enough of the forward-deployed engineer’s work can eventually be automated through software. That may work, and if any company has the technical DNA to attempt it, Google is an obvious candidate.
But I do not think the forward-deployed engineer disappears.
More importantly, that may be the wrong question.
The real question is: what new enterprise infrastructure makes human-AI collaboration reliable enough for complex, regulated, high-stakes environments?
This piece is part of The Enterprise AI Coordinate System.
Every AI lab is hiring forward-deployed engineers to hand-structure the enterprise. Google is betting it can automate them away, because it has run this exact play once before and won a category with it.
Two models for organizing a corpus are competing for the enterprise, and only one of them is new. The split surfaced this month in The Information, which laid out how far the major AI companies will go to make corporate data usable by their models, and how sharply Google has chosen to break from everyone else.
In the first model, you hire people. The role is the forward-deployed engineer, a term Palantir popularized for specialists who embed with a customer to wire messy, proprietary data into something an AI can reason over. Following that playbook, OpenAI, Anthropic, Microsoft, and Amazon are now spending billions to hire them by the thousand.
The work is unglamorous and essential: reconciling the four definitions of “gross revenue” living in four systems, mapping which tables mean which things, and teaching the model the distinction before it routes an invoice or onboards a hire. It is careful, expensive, linear labor. Every deployment consumes engineer-hours, and the next one starts again near zero.
In the second model, you automate the people away. That is the position Google staked out in the same reporting through Andi Gutmans, the Google Cloud vice president who runs its database and data products, and the executive who would own this strategy if anyone does.
Google is hiring some forward-deployed engineers of its own, he told The Information, but it is automating the core of what they do: the labor of organizing a company’s data so agents can use it.
His justification is the tell. You cannot, he argues, hire your way to full coverage. Activating all of an enterprise’s data requires a level of headcount no company can afford, so the only route to it is software. He points to a customer arriving with twenty thousand tables to make agent-ready, a job no achievable number of data stewards ever finishes.
What Google’s automated engineers produce, in his telling, is what the human ones did, but at machine scale. They read across a customer’s files, contracts, and databases to work out how everything relates, then emit context-rich structures, including knowledge graphs and semantic layers, that let an agent handle multi-step tasks such as routing invoices or onboarding employees without re-deriving the meaning of the data every time.
The reporting’s headline case is Virgin Media O2, the British telecom, which used Google’s agents to connect twenty thousand separate datasets, work a Google spokesperson framed as removing thousands of manual hours.
The product is called Knowledge Catalog, and Gutmans casts it as Google’s edge over Palantir, which announced a similar AI-powered engineer earlier in the year, because Google can combine the catalog with DeepMind’s research and turn Gemini on its own agents to check their work.
He also concedes the agents are not foolproof. Customers still assign people to vet the output, and the human role is supposed to shrink over time: first a period where people step in to say yes or no, then, as the system accumulates context, something closer to fully automatic.
That justification is not a product claim.
It is Google’s founding thesis, restated twenty-seven years later.
The forward-deployed-engineer strategy and Gutmans’s remarks were reported by The Information. The product mechanics, the “$42 problem,” and the knowledge-gap loop below are drawn from Google Cloud Next ’26 sessions and Google Cloud documentation.
The web had the same problem the enterprise has now: too much unstructured material, growing too quickly for people to organize by hand. The dominant answer in the late 1990s was the directory, with Yahoo’s editors and the volunteers of the Open Directory Project cataloguing the web link by link into a taxonomy maintained by humans.
It was the forward-deployed model applied to the internet: judgment, on-site, one entry at a time.
Google’s insight was that the directory could not scale against an exponential corpus, and did not need to. Crawl everything, resolve what the pages are about, build an index, rank by relevance to intent, and the human catalog becomes redundant. The company that industrialized the automated structuring of a chaotic corpus won the category outright, and the directories became a footnote.
The forward-deployed engineer is the directory editor of the enterprise-AI era.
Gutmans’s argument is the crawler argument ported inside the firewall: you cannot hand-catalog your way to full coverage, so the structuring itself has to become software.
The Virgin Media O2 result is the shape of the claim, if not yet its proof. One vendor case is a direction, not a verdict, and it says nothing about the part of the estate a company has never queried.
The product behind this bet is Knowledge Catalog, and it is worth being precise because the mechanism is where the strategy stops being a slogan and becomes testable.
It is not a new product. Google’s own team opens its launch by setting the record straight: this is Dataplex, renamed in April 2026 and repositioned from a governance tool for data engineers into what it calls an always-on context engine for agents. The underlying APIs did not change.
The positioning moved much further than the code did, which is itself the strategic disclosure.
Google decided the metadata layer was no longer plumbing. It was the prize.
Google’s own analogy gives the game away. It describes the enterprise as a map of roads, and the agent as a self-driving car capable of traveling from any point to any other but unable to do so intelligently until something tells it where those points are. Context is that map.
The company reaching for a maps metaphor to explain enterprise AI is, not incidentally, the company that owns the map.
But the deeper admission comes next: the map is not actually stored anywhere. It has to be assembled from signals scattered across every system.
Which means Google has to manufacture the structure it intends to own.
The machine runs on three pillars, in Google’s own naming.
Knowledge Catalog harvests metadata from Google’s own estate, including BigQuery, AlloyDB, Spanner, Cloud SQL, Looker, and Firestore. More importantly, it reaches beyond Google into unstructured files and rival catalogs including Collibra, Atlan, SAP, DataHub, and Ab Initio, with bidirectional exchange where supported.
The design intent is plain: leave no silo uncrawled, including silos that belong to competitors.
This is the part that begins to replace the forward-deployed engineer.
Gemini generates natural-language descriptions of tables and fields, recommends glossary terms, and performs the two moves that matter most: inferring relationships between assets by mining query logs, and proposing validated SQL patterns that encode how a business actually computes a thing.
The relationship inference is explicit about its signal. The system reads query logs, then applies the model to surface joins no schema declares. Extend the same machinery to unstructured content and it can extract entities and relationships from documents that were never tabular to begin with.
Agents pull that context through an API at query time, over a semantic-search layer Google explicitly says is built from its search stack. In its own framing, Google is a search company, and it has moved the same machinery inside the catalog.
Access is inherited from source systems: an agent sees only what its caller is authorized to see.
Read the three pillars back and the architecture is unmistakable:
Aggregate → enrich → retrieve.
Against the enterprise instead of the web. Harvest, resolve, serve, with the model now helping perform the interpretation once supplied by humans.
The moat in search was never just the algorithm. It was the index, the structured layer between the query and the corpus that decided what the ranking ever got to see. Knowledge Catalog is an attempt to build that same layer, one per customer, inside the firewall.
Google says as much on stage. Every agent it ships in its own data cloud is built to hit the catalog for context first, before it does anything else.
The context layer is not another feature in the stack.
It is the thing the rest of the stack now asks permission from.
The best illustration of what this machine can and cannot do came not from Google but from a customer on its stage: a Bloomberg Media team walking through what they called the $42 problem.
Ask an agent for monthly net revenue. Net revenue is earned money minus transactional expenses; the SQL itself is undergraduate. The agent finds the billing table, finds the disputes table, writes clean, syntactically perfect code, and returns a number that is wrong.
The number is wrong because this particular company’s payments vendor charges a forty-two-dollar fee on every disputed transaction. The rule is contract-specific, lives in no schema, and was documented once in a 2017 wiki page whose author has since left the company. A capable human analyst, handed the same tables, made the identical mistake for the identical reason.
The failure was not a data problem. It was a knowledge problem, and the knowledge was in nobody’s database and nobody’s head that was still on payroll.
This is the wall every automation bet eventually hits. Structure inferred from schemas and query logs can recover what the organization does. It cannot recover a rule that lives only in a lapsed contract, an old wiki page, or a departed employee’s memory.
Usage is not authority.
No amount of crawling the data plane surfaces the forty-two dollars if nothing in that data plane knows it exists.
Google’s answer is the genuinely clever part, and it deserves credit before it gets its caveats.
The customer built a second agent, a knowledge-gap agent, whose job is to watch the first one fail. It reads the failed query, the user’s correction, and the surrounding context; reasons about what the agent did versus what it should have done; drafts a structured update to the catalog, such as a definition, join rule, or caveat; and, after a human certifies it, writes that knowledge back permanently.
The forty-two-dollar rule, learned once from a single wrong answer, becomes catalog knowledge every future agent inherits. In a twenty-table pilot, the loop generated roughly a hundred such notes and increased the agent’s SQL accuracy by a claimed sixty-three percent.
That is a real answer to the objection that automation only structures what is already legible.
It manufactures new context from failure.
But read the loop closely and it confirms the deeper limits rather than eliminating them.
Someone still eats the first wrong answer. The system learns the missing rule only after an agent has already returned a bad revenue number to someone who trusted it.
A human still certifies every update. The authority problem has not been automated away. It has been formalized into a review step, which is the honest place for it to live and also the point where the “fully agentic” story quietly ends.
And the correction remains fragile until it is written back. In the demo, a fee change lived only inside one session and reverted the moment a new session began.
Context, in this architecture, is not a thing you have. It is a thing you must keep manufacturing, forever, against a corpus that keeps changing underneath you.
Two months after the rebrand, in June 2026, Google published the Open Knowledge Format, a deliberately minimal, vendor-neutral specification for agent-readable knowledge.
A bundle is a directory of Markdown files with YAML frontmatter, one concept per file, linked by ordinary Markdown links that form a graph. One required field. No SDK, no runtime, no proprietary API. It ships in Git, renders on GitHub, and can be read by any agent.
Knowledge Catalog ingests the format natively, while the catalog itself is repeatedly positioned as an open ecosystem without vendor lock-in, including bidirectional metadata exchange with rival catalogs it also crawls.
Taken at face value, this cuts against everything above. A company trying to own the semantic layer is publishing an open format that makes semantic knowledge portable while boasting about interoperability with its competitors.
It is not a contradiction.
It is the 2011 move repeated.
Google seeded schema.org so publishers would structure their own pages in a vocabulary Google’s crawler could read. It was a genuine open standard that also happened to industrialize the supply of structured input to Google’s index.
The same mechanism applies here.
An open format is a solvent applied to everyone else’s lock-in, and a funnel into your own ingestion.
Enterprise knowledge currently sits trapped inside rival catalogs, proprietary APIs, semantic layers, documents, and databases. A portable format and bidirectional connectors dissolve part of that trap.
But once the knowledge is portable, where does it go?
The most convenient destination is likely to be the catalog whose vendor wrote the specification, built the reference tooling, and integrated the consumer. The reference implementation makes the gravity clear: the producer agent runs on Gemini, the demonstrated source is BigQuery, and the obvious consumer is Knowledge Catalog.
The license is neutral. The ecosystem is not.
This is also some of the strongest evidence that Google is playing for the layer rather than the services line.
You do not publish an open standard for a consulting practice.
You publish one for a substrate…
Send this story to anyone — or drop the embed into a blog post, Substack, Notion page. Every play sends rev-share back to The Business Engineer.
We’ve simplified responses to 👍 / 👎. Past comments are archived but no longer visible.