{"slug": "building-the-live-context-graph-for-agents-28-weekly-releases-later", "title": "Building the Live Context Graph for Agents, 28 Weekly Releases Later", "summary": "Materialize announced 28 weekly releases to build a live context graph for AI agents, enabling real-time data feedback loops. The platform now includes an MCP Server for agent discovery and querying, improved performance for agent-scale workloads, and enterprise-grade security features.", "body_md": "# Building the Live Context Graph for Agents, 28 Weekly Releases Later\n\nJune 16, 2026\n\nAgents need a tight feedback loop: observe data as context, act, and observe again to figure out if the actions were successful.\n\nImagine a logistics agent which has to:\n\n- reroute a late shipment\n- then read inventory and ETAs to confirm the reroute landed\n- finally, alert customers about the change\n\nTraditional solutions weren't designed for agentic feedback loops like this. OLTP databases can't keep up with the volume of complex queries, and warehouses can't maintain the data freshness required.\n\nThis era needs a new category of infrastructure; infrastructure that can keep data fresh, and consistent, so that agents have the feedback loop they need.\n\nI'm biased, of course, but I believe Materialize is the right tool for the job.\n\nIf you've followed us from the early days, you know the core idea: maintain views incrementally, so the result is already computed, and is served in milliseconds. Incremental view maintenance lets you easily build a *live context graph for your agents:* an interconnected set of data products, which represent key business objects such as Customers, Orders, or Shipments.\n\nWe've worked closely with customers like Bilt Rewards and Crane Worldwide Logistics to enable this pattern. 28 weekly Materialize releases later, we've made it easier to connect agents to your context graph, operate without a human in the loop, connect to all your data sources, and run with enterprise grade security.\n\nIf you want to start building right away, check out our [guide to get started now](/docs/get-started/quickstart/). But if you want to learn about what's new, read on!\n\n**Build and iterate on your context graph**\n\nAs mentioned in the introduction, we think of the *context graph* as an interconnected set of data products. In Materialize, data products are simply [materialized views](/docs/concepts/views/#materialized-views), or [indexed views](/docs/concepts/views/#indexes-on-views), which are kept up to date as data changes. Maintaining these data products is just step one though; you need to expose them to your agents and iterate on them.\n\n**Allow agents to discover & query data products, using our MCP Server for Agents**\n\n[The Materialize MCP Server for agents](/docs/integrations/mcp-server/mcp-agent/) allows your agents to discover and query data products. You can create an ontology of these data products, and expose the ontology to an agent so that it understands the relationships between your data. Once your agent understands the data, it can query & join.\n\nA benefit of Materialize's model is that you can create a bespoke data product for each agent if you want to. Using bespoke data products is optional, but it makes data governance simple using our RBAC model; just grant your agent `SELECT`\n\nprivileges on exactly the data it should see. To accomplish this with a data warehouse, you'd need to create \"just another pipeline\" and introduce more lag. On Materialize it's just a few lines of SQL. And you can trust that your agent's bespoke data product will remain correct and fresh.\n\nThe MCP server for Agents is available today, and endpoints are included with every Materialize environment.\n\n**Performance for agent-scale workloads**\n\nAgents query far more aggressively than humans or dashboards do. So we've significantly increased maximum queries per second, connections per second. We've improved tail latency; in our tests we saw 50% reductions in p99 latency.\n\nWe've also shipped optimizations that substantially reduce CPU usage for views with [temporal filters](/docs/transform-data/patterns/temporal-filters/), making these viable for agent scale workloads. While specific results are workload dependent, in our tests, we saw CPU usage drop substantially.\n\n**Iterate on the context graph, using replacement materialized views**\n\nMaterialize allows you to build cascading data products, for instance, a materialized view which reads from another materialized view. Since all the materialized views are maintained incrementally, this topology is very cheap to maintain. But as you can imagine, with a cascade of downstream dependencies, iterating on a data product can be hard. With replacement materialized views, we're making it much easier.\n\nImagine you're a logistics firm, with a data topology like this. And imagine you've accidentally introduced a bug in the `shipment_status`\n\nmaterialized view:\n\nFrequent Materialize users know the drill for deploying changes to their data products: a full [blue/green deployment](/docs/manage/dbt/blue-green-deployments/). This works well, but it temporarily doubles resource costs, and requires tight coordination between teams.\n\n[Replacement materialized views](/docs/transform-data/updating-materialized-views/replace-materialized-view/) are more surgical. You can make an in-place change to a single materialized view and have the change flow downstream, without recreating dependent objects and without downtime.\n\n`1` | \n\n```\n-- Replacement with the corrected logic. It hydrates in the background while\n```\n\n |\n`2` | \n\n```\n-- shipment_status keeps serving reads.\n```\n\n |\n`3` | \n\n```\nCREATE REPLACEMENT MATERIALIZED VIEW shipment_status_v2\n```\n\n |\n`4` | \n\n```\nFOR shipment_status AS\n```\n\n |\n`5` | \n\n```\nSELECT\n```\n\n |\n`6` | \n\n```\n    s.id          AS shipment_id,\n```\n\n |\n`7` | \n\n```\n    s.carrier,\n```\n\n |\n`8` | \n\n```\n    s.origin,\n```\n\n |\n`9` | \n\n```\n    s.destination,\n```\n\n |\n`10` | \n\n```\n    s.promised_at,\n```\n\n |\n`11` | \n\n```\n    s.delivered_at,\n```\n\n |\n`12` | \n\n```\n    -- Fixed: late if it was delivered after the promise, OR it's still\n```\n\n |\n`13` | \n\n```\n    -- in transit and we're already past the promised time (evaluated live).\n```\n\n |\n`14` | \n\n```\n    (s.delivered_at > s.promised_at)\n```\n\n |\n`15` | \n\n```\n      OR (s.delivered_at IS NULL AND s.promised_at < mz_now()) AS is_late\n```\n\n |\n`16` | \n\n```\nFROM shipments s;\n```\n\n |\n\nThe replacement materialized view will hydrate. Once the replacement is ready, you can apply the change. Materialize will calculate a diff between the original and the replacement, and all the changes flow downstream seamlessly.\n\n`1` | \n\n```\n-- Once shipment_status_v2 has hydrated, swap it in. The corrected definition\n```\n\n |\n`2` | \n\n```\n-- takes over in place, the replacement is dropped, and the is_late diff flows\n```\n\n |\n`3` | \n\n```\n-- to late_by_carrier and the serving index -- nothing downstream is recreated.\n```\n\n |\n`4` | \n\n```\nALTER MATERIALIZED VIEW shipment_status\n```\n\n |\n`5` | \n\n```\nAPPLY REPLACEMENT shipment_status_v2;\n```\n\n |\n\nThis sounds conceptually simple, but there's a lot of complexity under the hood. Materialize operates on live streams of changing data, and ensuring the replacement emits a correct diff to downstream consumers is not trivial. If you want to learn how we built it, read [our deep dive on self-correcting materialized views](/blog/self-correcting-materialized-views/).\n\n**Moving towards a headless developer experience**\n\nIf agents are going to consume your data, they should help you operate it too. We're building Materialize to be operable end to end without needing a human in the loop, in what we think of as a headless developer experience.\n\n**Make coding agents productive with our developer MCP server and agent skills**\n\nMaterialize environments now include a built-in [Developer MCP endpoint](/docs/integrations/mcp-server/mcp-developer/). Point your coding agent like Claude Code at the developer MCP server and ask questions like \"why isn't this view fresh?\". Your coding agents will be able to receive telemetry from Materialize to diagnose the problem.\n\nThe developer MCP server pairs perfectly with our [coding agent skills](/docs/integrations/coding-agent-skills/). These skills give Claude Code and other agents working knowledge of Materialize: idiomatic SQL, indexing strategy, and troubleshooting playbooks. To use our skills, make sure you have Node.js (v16 or later) installed, and then run `npx skills add MaterializeInc/agent-skills`\n\n.\n\n**Faster development for software engineers and coding agents with mz-deploy**\n\nWe're excited to introduce v0.1 of **mz-deploy**, a new CLI for declarative Materialize deployments. You (and your coding agents) can use mz-deploy to define sources, views, indexes, clusters, and other Materialize objects as code.\n\nBut mz-deploy is more than a deployment tool. It brings a software engineering workflow to Materialize. Projects compile locally with no running Materialize instance required. You can run unit tests, inspect query plans, and validate changes entirely inside a sandbox. That means developers, and coding agents like Claude Code, Cursor, and Codex, can safely author and validate changes before ever touching a shared environment.\n\nIt's fast, too. Built in Rust, mz-deploy can cold compile a project with more than 40,000 models in under 500ms, with most incremental changes compiling in under 10ms.\n\nDeployments are faster as well. mz-deploy only redeploys objects that have changed, supports blue-green deployments, and allows multiple deployments to proceed concurrently. If overlapping changes occur, conflict detection at promote time keeps things safe.\n\nmz-deploy is an alternative to using [dbt](/docs/manage/dbt/get-started/). Our dbt adapter is still supported; we're still making improvements to it, and it's still a great way to manage Materialize. But if you're interested in the future of the Materialize developer experience, we'd love for you to give mz-deploy a try, using our [instructions here](/docs/manage/mz-deploy/).\n\n**Don't ignore the humans: new UIs in the console**\n\nWhile we're building towards a headless future, we're not ignoring human-readable observability. The new Objects UI in the Console lets you diagnose object freshness directly. If lag is inherited from upstream, you can visualize the critical path to find where it originates. If the object itself is the cause, you can drill into the root cause.\n\nWe've also added a new Roles and Users page to help you track the hierarchy of roles, and manage permissions. We all know that changing permissions via clickops isn't durable; so the new UI exposes equivalent terraform and SQL commands so you can make it durable.\n\n**Up to 75% faster DDL**\n\nFinally, for large-scale environments, we've sped up DDL by as much as 75%, making large deployments and schema migrations faster.\n\n**Connect to all your sources and sinks**\n\nA context graph is only as good as its edges. This wave of releases expands both what Materialize can ingest and where it can deliver results.\n\n**Deliver to your warehouse with the Iceberg sink**\n\nMaterialize keeps the operational, fresh view of your data; your lakehouse is the right place for history. The new [Iceberg sink](/docs/sql/create-sink/iceberg/), in public preview, delivers exactly-once updates to Apache Iceberg tables on AWS S3 Tables, with GCP support coming very soon:\n\n`1` | \n\n```\nCREATE CONNECTION aws_connection TO AWS (\n```\n\n |\n`2` | \n\n```\n    ASSUME ROLE ARN = '<IAM role ARN>',\n```\n\n |\n`3` | \n\n```\n    REGION = '<region>'\n```\n\n |\n`4` | \n\n```\n);\n```\n\n |\n`5` | |\n`6` | \n\n```\nCREATE CONNECTION iceberg_catalog TO ICEBERG CATALOG (\n```\n\n |\n`7` | \n\n```\n    CATALOG TYPE = 's3tablesrest',\n```\n\n |\n`8` | \n\n```\n    URL = 'https://s3tables.us-east-1.amazonaws.com/iceberg',\n```\n\n |\n`9` | \n\n```\n    WAREHOUSE = '<S3 table bucket ARN>',\n```\n\n |\n`10` | \n\n```\n    AWS CONNECTION = aws_connection\n```\n\n |\n`11` | \n\n```\n);\n```\n\n |\n`12` | |\n`13` | \n\n```\nCREATE SINK orders_history\n```\n\n |\n`14` | \n\n```\n  IN CLUSTER sink_cluster\n```\n\n |\n`15` | \n\n```\n  FROM orders_summary\n```\n\n |\n`16` | \n\n```\n  INTO ICEBERG CATALOG CONNECTION iceberg_catalog (\n```\n\n |\n`17` | \n\n```\n    NAMESPACE = 'analytics',\n```\n\n |\n`18` | \n\n```\n    TABLE = 'orders_history'\n```\n\n |\n`19` | \n\n```\n  )\n```\n\n |\n`20` | \n\n```\n  USING AWS CONNECTION aws_connection\n```\n\n |\n`21` | \n\n```\n  MODE APPEND\n```\n\n |\n`22` | \n\n```\n  WITH (COMMIT INTERVAL = '60s');\n```\n\n |\n\nAppend-only mode is particularly useful with [temporal filters](/docs/transform-data/patterns/temporal-filters/); as rows age out of your real-time view in Materialize, the full record is preserved in Iceberg for historical analysis.\n\nThe Iceberg sink can simplify your data stack greatly. If you're replicating data into Materialize for operational work already, use the Iceberg sink to replace batch pipelines from your OLTP databases to your OLAP warehouses.\n\n**Copy static data from object storage**\n\nNot everything is a stream. [COPY FROM](/docs/sql/copy-from/) now supports bulk loading CSV and Parquet files from S3 and S3-compatible object storage, including multi-file loads. It's useful if you have to load features from a machine learning run or load historic data that will no longer change.\n\n`1` | \n\n```\nCOPY INTO events FROM 's3://example_bucket'\n```\n\n |\n`2` | \n\n```\n  (FORMAT PARQUET, AWS CONNECTION = aws_conn, PATTERN = 'events/**');\n```\n\n |\n\n**Handle upstream schema changes with source versioning**\n\n**Source versioning** is now in public preview, and available across all our OLTP sources (PostgreSQL, MySQL, and SQL Server). It lets you handle upstream schema changes such as added or dropped columns with zero downtime, by creating a new version of a source table.\n\nSay a `shipments`\n\ntable in your upstream Postgres gets a new `carrier`\n\ncolumn. Your existing table keeps ingesting the old schema with no interruption. To pick up the new column, recreate the table from the same source in a new schema:\n\n`1` | \n\n```\n-- v1.shipments was created earlier and keeps running untouched.\n```\n\n |\n`2` | \n\n```\nCREATE SCHEMA v2;\n```\n\n |\n`3` | |\n`4` | \n\n```\nCREATE TABLE v2.shipments\n```\n\n |\n`5` | \n\n```\n  FROM SOURCE pg_source (REFERENCE public.shipments);\n```\n\n |\n`6` | |\n`7` | \n\n```\n-- v2.shipments snapshots with both the old and new columns,\n```\n\n |\n`8` | \n\n```\n-- so downstream views can now reference carrier.\n```\n\n |\n`9` | \n\n```\nCREATE MATERIALIZED VIEW v2.late_by_carrier AS\n```\n\n |\n`10` | \n\n```\nSELECT carrier, count(*) AS late_shipments\n```\n\n |\n`11` | \n\n```\nFROM v2.shipments\n```\n\n |\n`12` | \n\n```\nWHERE delivered_at > promised_at\n```\n\n |\n`13` | \n\n```\nGROUP BY carrier;\n```\n\n |\n\nDropping a column works the same way: recreate the table in a new schema, excluding the column before you drop it upstream.\n\n`1` | \n\n```\nCREATE SCHEMA v3;\n```\n\n |\n`2` | \n\n```\nCREATE TABLE v3.shipments\n```\n\n |\n`3` | \n\n```\n  FROM SOURCE pg_source (REFERENCE public.shipments)\n```\n\n |\n`4` | \n\n```\n  WITH (EXCLUDE COLUMNS (carrier));\n```\n\n |\n\n**Performance improvements**\n\nWe've improved memory usage on sinks, by as much as 50%. We've also sped up snapshot times on PostgreSQL sources; some customers saw initial snapshot times improve by as much as 8x.\n\n**Enterprise readiness**\n\n**SSO and OIDC support on Self-Managed**\n\nSelf-Managed Materialize now supports Single Sign-On (SSO), via OpenID Connect (OIDC). This means you can manage and provision users through your identity provider. It's backwards compatible; username and password authentication continues to work, which matters for tools like Looker that can't complete an OIDC flow.\n\nWe're investing heavily in our enterprise authentication offerings, and plan to launch support for SCIM and role-mapping in the near future. [Follow our guide](/docs/security/self-managed/sso/) to get started with SSO on Self-Managed.\n\n**HA database support on Self-Managed**\n\nIf your upstream runs on an HA configuration like GCP Cloud SQL HA or SQL Server Always On, Materialize now continues ingesting through a failover.\n\n**One weekly release at a time**\n\nWe ship weekly version updates at Materialize. While we've always done this on our managed cloud product, six months ago we began doing the same for our [Self-Managed](/product/self-managed/) product as well. As soon as we did, something unusual happened: our Self-Managed customers actually upgraded.\n\nWhile most self-managed infrastructure products measure new version adoption in quarters, many of our customers upgrade within days. They upgrade frequently because each upgrade is stable, and adds functionality they need to power their agents.\n\nAs I mentioned in the introduction, we're built around novel primitives, including incremental view maintenance. Incremental view maintenance is the right primitive for the agent era because the volume of reads & writes is exploding. If you want agents to act on fresh context, you can't recompute the world on every query; it's much better to keep views up to date incrementally and serve them in milliseconds.\n\nWe're still shipping weekly. If you're already running Materialize, upgrading is the easiest it's ever been; follow our [upgrade guide](/docs/self-managed-deployments/upgrading/). If you're new, [choose the deployment model](/get-started/) that works for you, and get started today.", "url": "https://wpnews.pro/news/building-the-live-context-graph-for-agents-28-weekly-releases-later", "canonical_source": "https://materialize.com/blog/building-the-live-context-graph-for-agents/", "published_at": "2026-06-16 14:06:58+00:00", "updated_at": "2026-06-16 14:19:42.444322+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools", "developer-tools"], "entities": ["Materialize", "Bilt Rewards", "Crane Worldwide Logistics"], "alternates": {"html": "https://wpnews.pro/news/building-the-live-context-graph-for-agents-28-weekly-releases-later", "markdown": "https://wpnews.pro/news/building-the-live-context-graph-for-agents-28-weekly-releases-later.md", "text": "https://wpnews.pro/news/building-the-live-context-graph-for-agents-28-weekly-releases-later.txt", "jsonld": "https://wpnews.pro/news/building-the-live-context-graph-for-agents-28-weekly-releases-later.jsonld"}}