Architecting the Data Layer for AI Agents упирается не в нехватку данных, а в то, что данные не готовы к агентному доступу. Это меняет архитектуру: нужно решать, где держать источник истины, как снизить токен-оверход и как сохранить точность, security и cost.
Проблема здесь не в модели и не в количестве данных. Проблема в том, что традиционные transactional systems проектировались для приложений, а data lake — для аналитики и дашбордов. AI agents работают иначе: они задают много непредсказуемых запросов, чувствительны к latency и могут за минуты породить сотни обращений. Если подключить их напрямую к старой схеме без подготовки, система быстро упрётся в нагрузку, шум в данных и ограничения legacy databases.
Поэтому Fabiane Nardon описывает не одно решение, а набор компромиссов. Для свежих данных и write operations нужен transactional system, потому что data platform всегда немного запаздывает. Для historical data, semantic search и enrichment удобнее data platform, потому что там можно подготовить данные, почистить шум и добавить нужную семантику. Это не вопрос «что лучше», а вопрос, какой слой должен обслуживать конкретный workflow.
Дальше встаёт вопрос организации самого data layer. Здесь выбран data mesh, потому что он хорошо работает в компаниях, где данные распределены по доменам. Каждый domain владеет своим data product, а это означает не только данные, но и owner, stable interface contract, documentation, discoverability и quality SLA. Для архитектуры это важный сдвиг: данные начинают жить как управляемый сервис, а не как набор таблиц без ответственности.
Отдельно показателен подход к MCP tools. Команда связала каждый tool с data product и тем самым перенесла принципы governance в слой доступа для агентов. Это снижает хаос вокруг generic tools вроде get_schema или generate_query. Вместо универсальных, но расплывчатых интерфейсов появляются специализированные инструменты, которые знают предметную область и умеют извлекать данные точнее. Такой подход прагматичен: он немного усложняет моделирование, но заметно улучшает управляемость и ответственность.
Однако даже хорошая архитектура данных не решает semantic problem. Внутри одной компании одни и те же термины могут означать разное. Active customer, churn или другие базовые понятия часто расходятся между marketing, finance и другими доменами. Для людей это терпимо, потому что контекст накапливается через общение. Для LLMs и agents это слабое место, потому что они не могут полагаться на неявное знание команды. Поэтому Nardon указывает на Semantic Web и semantic ontologies как на способ сделать смысл данных явным.
Главная инженерная мысль здесь проста. Enterprise-grade agents нельзя строить поверх данных, которые остались оптимизированы только под человека или только под аналитика. Нужен слой, который умеет балансировать precision, security и cost. Нужны разные пути доступа для разных задач. Нужны data products с владельцами и контрактами. И нужны семантические модели, чтобы агент не путал формально похожие, но бизнес-значимо разные сущности.
В тексте нет числовых метрик выигрыша, кроме общего тезиса о снижении token overhead и оптимизации context windows. Но сам архитектурный вывод ясен: подготовка data layer становится частью инженерного контура AI-системы, а не вспомогательной задачей. И чем сложнее enterprise-среда, тем сильнее этот слой влияет на точность ответов, стоимость запросов и предсказуемость поведения системы.