Is Software Losing Its Head? | Andreessen Horowitz
Статья a16z обсуждает, что объявление Salesforce о запуске headless-продукта и открытии API ставит ключевой вопрос: где сохраняется защитный ров (moat) у систем записи (system of record) в эпоху AI-агентов. Раньше липкость обеспечивал UI, привычки пользователей и встроенные процессы, но агенты, читающие данные напрямую через API и MCP, разрушают эту модель. Авторы (Seema Amble при поддержке Angela Strange) разбирают исторические факторы устойчивости — частота использования, write-read характер, недокументированные SOP, зависимости, compliance — и показывают, как они смещаются. Покупатель теперь выбирает между: добавлением агентов к incumbent-системе, полным DIY или AI-native заменой. Новые источники защитности — сложность воссоздания данных, уникальный proprietary data, владение action layer (закрытый цикл от действия до обратной связи), привязка к реальному миру (логистика, field-services), сетевые эффекты в мультистороннем workflow и техническая зрелость покупателя. Главный вывод: следующее поколение систем записи будет агентским, будет генерировать контекст и data exhaust, и расширится в реальное исполнение, а сами данные уйдут на задний план.
Теряет ли софт свою «голову»?
Теряет ли софт свою «голову»? Содержание
Теряет ли софт свою «голову»?
В прошлом месяце Salesforce объявил, что откроет свои API и запустит headless-продукт, по сути сделав ставку на то, что в агентском мире его ценность лежит в слое данных, а не в UI. Это умное репозиционирование. (Хотя стоит отметить, что технически почти ничего не изменилось: API, которые Salesforce теперь продвигает как «headless-продукт», существуют уже много лет. Иными словами, это был классический маркетинговый запуск Salesforce.) Идея нового продукта в том, что агенты могут обращаться к данным системы записи, не взаимодействуя с UI, который рассчитан на людей, отслеживающих рабочие процессы.
Это объявление — хороший повод задать более интересный вопрос: если убрать UI и обнажить базу данных, что у вас на самом деле остаётся? Чем это отличается от Postgres-базы с хорошо спроектированной схемой и API? Сохраняются ли классические факторы, благодаря которым системы записи остаются устойчивыми, или появляется новый набор критериев? В эпоху SaaS система записи была защищена тем, что люди жили в интерфейсе. В агентскую эпоху это преимущество ослабевает. Защитные слои смещаются вниз — в модели данных, разрешения, логику процессов и compliance, — и вверх — в сети, генерацию проприетарных данных и исполнение в реальном мире.
Когда софт становится headless, куда смещается защитность?
UI и был продуктом
Система записи — это авторитетный источник истины для определённого домена бизнес-данных. Это место, где живёт официальная версия отношений с клиентом, записи о сотруднике или финансовой транзакции — система, из которой другие инструменты читают и в которую записывают. CRM — это система записи для выручки. HRIS — система записи для людей. ERP — система записи для денег. Их сила не в том, что они просто хранят данные, а в том, что они становятся общей реальностью, в которой работает вся организация.
Последние два десятилетия Salesforce продавал способ управления командами продаж. Дашборды, представления пайплайна, инструменты прогнозирования и ленты активности — вот что покупали люди. Их бизнес-модель строилась на продаже seats пользователям, которым предоставлялся доступ к этим функциям. Лежащая под ними база данных была критична, но второстепенна.
А значит, именно UI обеспечивал липкость. Он принуждал к гигиене данных. Он создавал общий словарь: Leads, Opportunities, Accounts. Он заставлял тысячи менеджеров по продажам вводить данные, которые иначе они бы не ввели. UI был механизмом, который поддерживал когерентность данных. Продукт настолько липкий, что многие руководители продаж настаивают на переносе Salesforce на новую работу — не потому, что UI хорош, а потому, что это мышечная память.
Агенты начинают переворачивать эту модель. Вместо взаимодействия через UI они могут читать и писать напрямую в данные, что породило волну новых инструментов и обходных решений, полностью обходящих интерфейс (Salesforce здесь не единственный пример: мы недавно писали о том, как вокруг SAP разрастается целая AI-дружественная экосистема). Computer-using агенты также со временем делают устаревшими традиционные «человеческие» факторы — предпочтения, обучение, недокументированный контекст. Иными словами, требования к тому, чтобы быть устойчивой системой записи, эволюционируют.
Историческая оценочная карта
Прежде чем спрашивать, что меняется в агентском мире, стоит точно понять, что изначально делало систему записи липкой. Первые несколько факторов фокусируются на том, как люди взаимодействуют с софтом и их предпочтениях. Софт делали липким в основном UI, привычка, человеческий workflow и встроенный процесс.
Насколько часто к нему обращаются? CRM используется каждый день GTM-командой и не только. Эта частота делает его критической инфраструктурой, а человеческий слой поверх него — ритуалы, мышечная память, управленческие каденции, выстроенные годами, — часто оказывается самым трудным для миграции, потому что его даже не воспринимают как то, что требует миграции.
Это write-only или read-write? Липкая SoR — это read-write SoR. CRM, например, не write-only архив; из него постоянно читают. Каждый зафиксированный звонок, каждое обновление стадии, каждая созданная задача введены кем-то (кто, предположительно, заботился о том, что делает). Этот двунаправленный поток означает, что любая замена должна работать с живыми операционными данными, а не только с историческим экспортом. Безопасного момента для переключения нет, поэтому предприятия, как правило, остаются с провайдером, как только подключились. На другом полюсе applicant tracking system (ATS) обычно write-only — после найма у вас мало причин возвращаться к данным.
Сколько недокументированных SOP? Критически важный для бизнеса контекст не живёт ни в какой wiki; он закодирован в правилах workflow, выстроенных годами админами и системными интеграторами. На примере продаж: недокументированный контекст в том, что enterprise-сделки свыше $100K требуют одобрения VP, EMEA-сделки требуют privacy review, а стратегические logo-скидки могут обходить финансы только в конце квартала. И именно этот контекст часто определяет, будет ли что-то сделано вовремя (или без нарушения важной практики) или не произойдёт вообще. Миграция означает реверс-инжиниринг каждой автоматизации или полную потерю институциональной памяти.
Много ли внутренних или внешних зависимостей? Ключевой вопрос: сколько внутренних систем, командных процессов или внешних стейкхолдеров зависят от этой системы записи. Внутренняя связанность — это другой софт или workflow ниже по потоку. Внешняя связанность — это внешние стороны вроде аудиторов, бухгалтеров или регуляторов, которым нужен прямой доступ к данным (как для ERP). Чем выше связанность по любому измерению, тем больше придётся распутывать при миграции.
Насколько критичны данные с точки зрения compliance? Ключевой вопрос здесь прост: является ли система compliance-критичной? Compliance-критичные системы — payroll, ERP, HR-данные — требуют юридически защищённого источника истины, строгого контроля админ-доступа и прямого участия аудиторов и регуляторов в любой миграции. Это делает их значительно более липкими. Данные о продажах и инструменты поддержки клиентов вроде Zendesk на другом конце спектра: важна непрерывность и контекст, но регуляторных рисков при перемещении данных или предоставлении доступа нет.
Не все системы записи имели одинаковую стоимость переключения. Сравните CRM с Applicant Tracking System (ATS) по тем же измерениям — и разрыв очевиден. ATS — это workflow-инструмент для ограниченного процесса: рекрутинга. После того как кандидат нанят или отклонён, запись по большей части write-once. Интеграции уже. Пользовательская база мала и сконцентрирована.
ERP на другом полюсе: ledger — это аудит-трейл, а ваши бухгалтеры, аудиторы и регуляторы становятся прямыми стейкхолдерами в любой миграции. Заменить ATS болезненно, но переживаемо. Заменить CRM — операция на открытом сердце. Заменить ERP — операция на открытом сердце, пока пациент бежит марафон.
Исторически системы записи не пользовались такими создателями рва, как проприетарные данные или сетевые эффекты; workflow обычно сам по себе создавал достаточный ров. Если что, потребительские бизнесы объединяли инструмент и сеть; системы записи исторически этого не делали.
Проприетарные данные — Хотя многие системы записи собирали данные клиентов, они мало что с ними делали (и часто контрактно не могли). Так что хотя у CRM есть богатый набор данных и она могла бы агрегировать их между клиентами для генерации кросс-клиентских инсайтов, осмысленно этого никогда не делалось (хотя были попытки вроде Einstein у Salesforce).
Сетевые эффекты — Священный Грааль — это были бы сетевые эффекты. CRM становится ценнее, потому что продавцы софта могут находить покупателей. Как и данные, сетевые эффекты исторически были в лучшем случае слабыми для систем записи.
Так что же остаётся, если UI исчезает и приходят агенты?
Агенту не нужен браузер. Ему нужны API, контекст, инструкции и возможность действовать. Две вещи сделали это возможным в масштабе: LLM стали достаточно способными, чтобы рассуждать. Теперь агент может прочитать контекст, сформировать план, выбрать инструменты, выполнить действия и проверить результат без человека в цикле для большинства задач. И MCP стандартизировал доступ к инструментам, дав агентам общий интерфейс для вызова внешних возможностей. Агент с MCP-доступом к вашей платформе может сделать то же, что делает пользователь-человек, за миллисекунды, в масштабе, без браузера. С правильным контекстом computer-using агенты должны уметь навигировать интерфейсы incumbent-софта даже без API.
Если упрощённо, то у покупателя софта теперь есть три пути:
1) Incumbent-система + агенты. Использовать CLI и API incumbent-а — либо через его нативный агентский продукт (Agentforce от Salesforce, Joule от SAP), либо строя собственных агентов поверх. (Сделав вид, что API полны и удобны, и что переход к headless не настолько операционно сложен, как он есть на самом деле.)
2) Сделать систему записи полностью самим (DIY). Построить собственную модель данных, операционную логику и такие вещи, как разрешения, аудит-трейлы, интеграции и т. д., и собственных агентов с нуля (вероятно, используя сторонние инструменты для построения агентов и БД).
3) Купить AI-native замену. Купить новое поколение софта, построенного с нуля под агентскую эру, рассчитанного на машинную читаемость, с оркестрацией агентов как first-class функцией, а не прикрученным сбоку. Это может быть headless.
Итак, что остаётся от старой оценочной карты? Элементы, определяемые человеческим поведением и предпочтениями, исчезают — например, частота доступа или read vs. read-write, которые связаны с человеческой мышечной памятью. Агенты могут убить мышечную память как ров, но они не убивают операционную логику и контекст как ров. Если что, они делают эту логику ещё важнее, потому что агентам нужны явные правила, разрешения и определения процессов, чтобы действовать безопасно.
Недокументированные SOP остаются важны в краткосрочной перспективе. Институциональная логика, закодированная в ваших правилах workflow, — это именно то, что нужно агентам, чтобы работать корректно от вашего имени. Это также самое трудное для реконструкции. Оно пока чисто не экспортируется, особенно когда в части процесса всё ещё участвуют люди. Однако захватывать контекст становится проще, и по мере того как агенты замещают всё больше труда, это становится менее релевантным.
Связанность по-прежнему трудно распутать, и она расширяется. Фактор связанности смещается. Дело уже не столько в том, чтобы успевать за людьми, сколько в поддержании связанности между традиционно изолированными функциями и софтом. CRM-агенту нужно сшивать данные и контекст по продажам, биллингу и customer success. А если ваша платформа также является узлом, через который агенты нескольких внешних организаций совершают сделки — покупатели, продавцы, партнёры, — зависимость углубляется ещё сильнее. Incumbent-у с агентами будет труднее работать поверх примитивов разного нижележащего софта, как и DIY-связке базы данных и агентов.
Compliance-критичные данные остаются важными. Данные для регуляторов или с регуляторным/юридическим риском требуют единого доверенного источника данных. Клиент менее склонен переключаться, если он доверяет существующему продукту. Возьмите данные payroll и бухгалтерии — агент может захотеть к ним обратиться, но вы вряд ли будете строить и поддерживать это in-house. В полностью агентском мире одна из самых трудных нерешённых проблем: какие агенты уполномочены делать что, от чьего имени, с какой возможностью аудита? Система записи, становящаяся слоем идентификации и разрешений для взаимодействий agent-to-agent, имеет структурную роль, которую действительно трудно вытеснить — не из-за данных, которые она хранит, а из-за архитектуры доверия, которую она навязывает.
Дальше для AI-native стартапов всё более релевантным становится следующий набор факторов, формирующих защитность:
Насколько трудно воссоздать SoR? — Данные начнут значить больше по нескольким причинам. Во-первых, в ближайшей перспективе важна лёгкость извлечения и воссоздания данных, лежащих в основе системы записи. AI делает это простым с помощью ряда инструментов, позволяющих пользователю это сделать. В ближайшей перспективе incumbent-ы могут и будут усложнять это, делая API мучительными, ограниченными, неполными или экономически непривлекательными — если API вообще предоставляются. Но по мере улучшения инструментов извлечения, особенно с развитием computer-using агентов, всё это будет даваться ещё легче. Параллельно, конечно, новые компании воссоздают более богатый набор данных из email, телефонных звонков и голосовых агентов, внутренних документов. AI снижает стоимость воссоздания первых 80% системы записи. Оставшиеся 20% — это исключения, согласования, требования compliance и edge-case workflow — по-прежнему отделяют полезный wedge от настоящей замены.
Есть ли значимые проприетарные данные? — Во-вторых, сами данные становятся интереснее. Защитные данные — это не те данные, которые вы импортируете; это данные, которые ваш продукт уникально порождает. Мы говорим о walled gardens данных — данных, которые либо проприетарны, либо регулируются, либо требуют постоянного обновления. Поставщик софта, инвестировавший в сбор авторитетных и полных данных, имеет преимущество перед универсальными поставщиками или конкурентами, у которых этих данных нет. Ещё один вектор вокруг данных — когда данные зависят от внутренне генерируемых действий. Лучшие бизнесы не просто складируют данные, введённые где-то ещё. Они генерируют новый data exhaust, находясь в цикле — это наблюдаемое поведение, response rates, временные паттерны, исходы процессов, бенчмарки, паттерны исключений и трассы производительности агентов. Ключевое здесь то, что данные теперь и есть контекст.
Владеет ли он action layer? — В старом мире хранение записи было достаточным. В новом мире агенты совершают действия, и защитность может смещаться к продуктам, способным работать в замкнутом цикле — от совершения действия до фиксации исхода и использования этой обратной связи для улучшения будущих решений. Для ERP это может быть согласование расходов, запуск payroll, сверка счетов, отправка уведомлений и т. д. Продукты, замыкающие цикл, более защищены, потому что они сидят внутри исполнения, а не наблюдения: они генерируют уникальные данные, улучшаются с использованием и становятся труднее удаляемыми без поломки workflow. Ценность здесь, конечно, растёт с количеством собранного контекста и обработанных edge-case.
Есть ли элемент исполнения в реальном мире? — Бизнес-модели со связанностью в реальные операции, которые не будут полностью автоматизированы. Очевидные примеры — бизнесы с выстроенной операционной сетью, как DoorDash, который исторически не был системой записи, но поучителен здесь. В более широком смысле любой софтверный бизнес, замыкающий цикл в сервисы, фулфилмент, логистику, полевые операции или платежи, имеет иной тип защитности, чем чистый SaaS. Эти компании не просто хранят запись или рекомендуют действие; они отправляют людей, перевозят товары или выполняют услугу.
Для строителей это говорит о возможностях в рынках, где софт всё активнее принимает решения, а агенты всё активнее координируют, но где «последняя миля» всё ещё требует исполнения в реальном мире. Например, вертикальный софт, привязанный к field services.
Есть ли сетевые эффекты? — Исторически сетевые эффекты были слабыми в большинстве систем записи, потому что софт был в основном внутренним. Но в агентском мире сетевые эффекты могут стать гораздо важнее, если система встроена в многосторонний workflow. Если система опосредует повторяющиеся взаимодействия между несколькими сторонами — покупателями и продавцами, работодателями и работниками, компаниями и аудиторами, вендорами и клиентами, плательщиками и провайдерами, — то каждый дополнительный участник может делать сеть полезнее для следующего.
Один способ — через общую координацию workflow: продукт становится местом, где обе стороны процесса совершают сделки, обмениваются контекстом и разрешают исключения. Другой — через бенчмаркинг и интеллект: система может выводить нормы, аномалии и рекомендации на основе паттернов, наблюдаемых по всей сети, что работает совместно с пунктом о данных выше. И третий — через доверие и стандартизацию: как только контрагенты начинают полагаться на одни и те же рельсы для согласований, передач, compliance или платежей, продукт становится труднее вытеснить, потому что он уже не просто база данных, а часть координационной инфраструктуры для самого рынка.
Насколько технически способен покупатель? — В мире, где теоретически каждый может построить собственных агентов, реальная способность покупателей сделать это сильно варьируется. Особенно в вертикальных конечных рынках и среди функциональных покупателей, у которых исторически не было сильных внутренних инженерных ресурсов, шансы того, что они построят, поддержат и непрерывно улучшат собственную базу данных, логику workflow, агентский стек и слой governance, остаются низкими. Стоимость здесь тоже имеет значение: DIY может в теории сократить лицензирование софта, но часто переносит расходы во внедрение, поддержку и внутреннюю сложность. Это означает, что есть реальная возможность в категориях, где операции покупателя операционно сложны, но технически недообслужены, что верно для большей части производства, бэк-офиса в строительстве, индустриальных и field-service workflow или для таких областей, как бухгалтерия.
Есть ещё несколько важных факторов, которые также будут table stakes для софта. Например, онтология должна быть другой. Большая часть рассуждений «DIY-база данных» недооценивает, сколько ценности живёт в самой объектной модели. Incumbent-софт строился под дашборды, отчёты и людей, фиксируя workflow. Это были opportunities, тикеты, кандидаты и т. п. Агентская схема должна захватывать рассуждения, действия, отслеживание состояния, обработку исключений, делегирование и координацию между системами. Нативной объектной моделью могут стать задачи, намерения, треды, политики или исходы.
Точно так же permissioning должен быть обновлён для управления агентами, а не только людьми. Это включает: кто что может делать, через какого агента, по какой политике, с какими согласованиями, с каким аудит-трейлом и с какой обработкой откатов / исключений.
И, конечно, всё это в контексте стоимости (например, сколько стоит строить и поддерживать агентов/базу данных, сколько стоит доступ к API), что снова возвращает к таким вещам, как сложность воссоздания данных и количество зависимостей.
Так к чему это нас приводит?
По мере того как incumbent-ы становятся headless, они делают неявную ставку на то, что слой данных останется источником ценности. В некоторых категориях, особенно глубоко связанных с compliance, как финансовые услуги, эта ставка может держаться какое-то время, и переход к headless может быть дальше. Для строителя софта возможность конкурировать с incumbent-ами по мере их перехода к headless и создавать устойчивый софт меняется. Следующее поколение систем записи уже начинает выглядеть иначе: не просто репозитории данных, собранных для логирования человеческой работы, а агентские — такие, что они захватывают контекст, инициируют работу и фиксируют data exhaust. Более того, самые интересные бизнесы расширятся в исполнение в реальном мире, координируя полевых работников, логистических провайдеров, сервисные команды и физические активы или сидя между несколькими сторонами. Они будут смешивать бизнес-модели старого мира, а ядро традиционной системы записи — данные — будет тем, что сидит на заднем плане.
Большое спасибо Angela Strange за совместное обсуждение этой темы!
Seema Amble
— партнёр в Andreessen Horowitz, фокусируется на инвестициях в B2B-софт и финтех.
Инвестируем в Tessera Labs Seema Amble, Eric Zhou и Joe Schmidt Почему мир по-прежнему работает на SAP Eric Zhou и Seema Amble Инвестируем в Lio Seema Amble, James da Costa, Eric Zhou и Brian Roberts Большие идеи 2026: слой enterprise-оркестрации Seema Amble, Angela Strange, Alex Immerman и David Haber Скорость нужна в AI-продажах: AI меняет не только то, что вы продаёте, но и то, как вы продаёте Seema Amble и James da Costa
Новости и ресурсы для навигации в мире B2B-технологий — от AI и данных до безопасности и SaaS и далее.
Хотите больше про Enterprise?
Новости и ресурсы для навигации в мире B2B-технологий — от AI и данных до безопасности и SaaS и далее.
Хотите больше про Enterprise?
Новости и ресурсы для навигации в мире B2B-технологий — от AI и данных до безопасности и SaaS и далее.
Мнения, выраженные в «постах» (включая подкасты, видео и социальные сети), принадлежат конкретным сотрудникам a16z, цитируемым в них, и не являются мнениями a16z Capital Management, L.L.C. («a16z») или её соответствующих аффилированных лиц. a16z Capital Management — инвестиционный консультант, зарегистрированный в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не предполагает наличия каких-либо особых навыков или подготовки. Посты не адресованы каким-либо инвесторам или потенциальным инвесторам и не являются предложением о продаже — или приглашением к покупке — каких-либо ценных бумаг и не могут использоваться или служить опорой при оценке достоинств какой-либо инвестиции.
Содержимое здесь — а также доступное на любых связанных платформах распространения и любых публичных онлайн-аккаунтах a16z в социальных сетях, на платформах и сайтах (вместе — «каналы распространения контента») — не должно рассматриваться или использоваться каким-либо образом как инвестиционная, юридическая, налоговая или иная консультация. Вам следует консультироваться с собственными советниками по юридическим, бизнес-, налоговым и иным связанным вопросам, касающимся любой инвестиции. Любые прогнозы, оценки, перспективы, цели, виды и/или мнения, выраженные в этих материалах, могут изменяться без уведомления и могут отличаться или противоречить мнениям, выраженным другими. Любые графики, предоставленные здесь или на каналах распространения контента a16z, носят исключительно информационный характер и не должны служить опорой при принятии каких-либо инвестиционных решений. Определённая информация, содержащаяся здесь, получена из сторонних источников, включая портфельные компании фондов под управлением a16z. Хотя она получена из источников, считающихся надёжными, a16z не проверял её независимо и не делает заявлений о её сохраняющейся точности или пригодности для конкретной ситуации. Кроме того, посты могут содержать рекламу третьих лиц; a16z не просматривал такую рекламу и не одобряет какое-либо рекламное содержимое в ней. Весь контент действителен только на указанную дату.
Ни при каких обстоятельствах никакие посты или иная информация, предоставленная на этом сайте — или на связанных каналах распространения контента, — не должны рассматриваться как предложение, побуждающее к покупке или продаже какой-либо ценной бумаги или доли в каком-либо пуле инвестиционных средств, спонсируемом, обсуждаемом или упоминаемом сотрудниками a16z. Они также не должны рассматриваться как предложение о предоставлении инвестиционно-консультационных услуг; предложение об инвестировании в управляемый a16z пул инвестиционных средств будет сделано отдельно и только посредством конфиденциальных предложений конкретных пулов инвестиционных средств — которые должны быть прочитаны полностью и только теми, кто среди прочих требований соответствует определённым квалификациям по федеральному законодательству о ценных бумагах. Такие инвесторы, определённые как аккредитованные инвесторы и квалифицированные покупатели, обычно считаются способными оценивать достоинства и риски предполагаемых инвестиций и финансовых вопросов.
Не может быть гарантий, что инвестиционные цели a16z будут достигнуты или что инвестиционные стратегии будут успешными. Любая инвестиция в средство под управлением a16z сопряжена с высокой степенью риска, включая риск потери всей инвестированной суммы. Любые упомянутые, ссылающиеся или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в средствах под управлением a16z, и не может быть гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь схожие характеристики или результаты. Список инвестиций, сделанных фондами под управлением a16z, доступен здесь: https://a16z.com/investments/. Прошлые результаты инвестиций a16z, пулов инвестиционных средств или инвестиционных стратегий не обязательно являются индикативными для будущих результатов. Из этого списка исключены инвестиции (и некоторые публично торгуемые криптовалюты/цифровые активы), для которых эмитент не предоставил a16z разрешения на публичное раскрытие. Что касается инвестиций в любой криптовалютный или токеновый проект, a16z действует в собственных финансовых интересах, не обязательно в интересах других держателей токенов. У a16z нет особой роли в этих проектах или власти над их управлением. a16z не обязуется продолжать иметь какое-либо участие в этих проектах, кроме как инвестор и держатель токенов, и другие держатели токенов не должны ожидать, что a16z будет это делать, или полагаться на это.
В отношении фондов под управлением a16z, зарегистрированных в Японии, a16z предоставит любому представителю японской общественности копию таких документов, которые требуется делать публично доступными в соответствии со статьёй 63 Закона Японии о финансовых инструментах и биржах. Пожалуйста, свяжитесь с compliance@a16z.com, чтобы запросить такие документы.
С другими условиями использования сайта можно ознакомиться здесь. Дополнительная важная информация о a16z, включая нашу форму ADV Part 2A Brochure, доступна на сайте SEC: http://www.adviserinfo.sec.gov.