Snap Engineering

Interesting approach — treating agent definitions the way Kubernetes treats infrastructure. The core idea is that your agent's identity, tools, constraints, and execution strategy all live in a single .agf.yaml file, and any runtime (LangChain, ADK, whatever) can execute it via adapters.

The engineering blog goes deeper into the motivation: https://eng.snap.com/agent-format

A few things that stood out to me:

The schema is grounded in POMDP formalism, which gives it a principled foundation rather than being yet another config format

There's a "tighten-only invariant" for multi-agent systems — child agents can never exceed their parent's constraints. Governance gets stricter as you go deeper, never looser

It explicitly separates agent-level constraints from org-level policies. The runtime composes both at execution time

They position it alongside MCP (tools) and A2A (agent communication) — three complementary layers rather than competing standards

The JSON Schema is published, there's an interactive playground on the site, and the spec itself is vendor-neutral. Curious if anyone has tried plugging this into their own stack.

I think this is an unhelpful comparison. Simply put, when users exchange messages on WhatsApp it causes minimal traffic to a WhatsApp data enter as it’s mostly p2p. No ads, no persistence.

Snapchat requires semi persistence for stories (viewable for 24hr) and millions of users can view a single story. When a celebrity posts a story and 5mil users view it that requires more engineering effort that p2p what’s app messages. Additionally, serving ads requires a large amount of compute (ad ranking/serving), storage (impressions), offline processing (Hadoop clusters are hard), engineering, salepeople, economists, and auxiliary systems to support advertisers buying ads, etc.

As an example, check out snaps blog post on ML and ads https://eng.snap.com/en-US/machine-learning-snap-ad-ranking