❌

Normal view

Received — 7 April 2026 ⏭ ai/automation

Verifying and optimizing post-quantum cryptography at Amazon

✇Amazon Science homepage
7 April 2026 at 15:00
Today, secure online communication is enabled by public-key cryptography, primarily RSA and elliptic-curve cryptography (ECC), whose security depends on the assumption that certain computational problems are intractable. However, while believed to be intractable for conventional computers, the problems underlying RSA and ECC may be tractable for sufficiently large quantum computers. “Store now, decrypt later” attacks — which intercept encrypted information and hold onto it until quantum computers can decrypt it — require protection against these attacks long before they become technically feasible. Post-quantum cryptography (PQC) is cryptography running on classical computers but secure in the face of quantum computing. In 2024, following an eight-year standardization effort, the US National Institute of Standards and Technology (NIST) published standard FIPS-203, which specifies the Module-Lattice-Based Key Encapsulation Mechanism, or ML-KEM, as a mechanism for key agreement believed to be secure against attacks from quantum computers. In this post, we describe how Amazon’s Automated Reasoning Group, AWS Cryptography, and the open-source community have collaborated to create an open-source, formally verified, and optimized implementation of ML-KEM, protecting customers against store-now-decrypt-later attacks with the highest assurance and minimal cost. What is good cryptographic engineering? In keeping with Amazon’s customer obsession, we prioritize three goals when working on cryptographic solutions: The security of the customer’s data: Cryptography is notoriously hard to implement securely, and any flaw can endanger the customer’s privacy; The customer experience: Cryptography is a computational tax that we minimize to ensure the lowest cost and best experience for our customers; Our ability to maintain the solution going forward: The less time we need to spend on maintenance, the more we can innovate on behalf of our customers. There are, however, tensions between these goals: Simple code is easiest to maintain and write securely but tends to be slow. Fast code tends to be more difficult to audit and prone to errors. Automated reasoning allows us to resolve these tensions and provide our customers with cryptographic solutions that are secure, fast, and maintainable, all at once. Yet another implementation of ML-KEM? ML-KEM — formerly known as Kyber — is well studied from an implementation perspective: On the one hand, the Kyber reference code provides a clean C implementation that has been scrutinized for years. On the other hand, numerous research papers describe how to optimize ML-KEM for various metrics and platforms. The challenge faced by AWS Cryptography and the Automated Reasoning Group in 2024 was to combine the simplicity of the reference implementation and the optimization potential revealed in the research works in a single production-ready implementation. Around the same time, AWS became a founding member of the Linux Foundation’s Post-Quantum Cryptography Alliance (PQCA), which created the Post-Quantum Cryptography Package (PQCP), “a collection of open-source projects aiming to build high-assurance software implementations of standards-track post-quantum cryptography algorithms”. Therefore, rather than brewing our own code, members of our team joined the PQCP and soon after launched mlkem-native, a high-assurance, high-performance C implementation of ML-KEM aiming to combine the ML-KEM reference implementation with research on optimization and formal verification. Coding, fast and slow Mlkem-native’s modular design combines a frontend covering the high-level logic of ML-KEM with a backend responsible for all performance-critical subroutines. Each subroutine — including the Keccak permutation underlying SHA3 and the number-theoretic transform (NTT) underlying fast polynomial arithmetic — has multiple, highly efficient implementations written natively for specific hardware. In addition to the default C implementation, mlkem-native provides assembly/intrinsics backends for AArch64, x86_64, and RISC-V64. Importantly for maintainability, the interface between frontend and backend is fixed: a developer adding optimizations for a new target architecture implements select backend functionality against the backend specification, while the frontend stays the same. The development of the backend specification turned out to be less obvious than it sounds, as we explain below. Knowing your limits Memory safety A well-known challenge with the C programming language is the risk of buffer overflows: writing past the designated limits of a memory region can corrupt data structures and, when maliciously exploited, lead to unprivileged code execution. The umbrella term for such issues is memory safety. Memory-safe languages such as Rust can limit the impact of out-of-bounds accesses — by, for example, panicking instead of exhibiting undefined behavior — but they don’t prevent the mistake itself. Type safety Another well-known challenge, this time with implementing ML-KEM, is the risk of integer overflows — an aspect of type safety. Like RSA and ECC, ML-KEM relies on modular arithmetic, in which the results of operations are divided by a particular number — in ML-KEM’s case, the prime 3,329, designated MLKEM_Q or just q — and only the remainder is carried forward. The modulo operator is represented by the percentage symbol, %. Logically, if two numbers x and y need adding or multiplying in ML-KEM, one needs to compute (x + y) % q and (x * y) % q; for example, (294 * 38) % q = 11,172 % q = 1,185. Such “eager” arithmetic modulo q, which constantly applies modular reduction to represent data in the “canonical” range {0, 1, 2, … , q-1}, is prohibitively slow. Efficient ML-KEM implementations instead use “lazy” arithmetic modulo q: data is operated on without modular reduction for as long as possible, and only once there is a worst-case risk of overflow does reduction happen. Further, this allows the use of imperfect reduction algorithms such as Montgomery reduction, which are fast but don’t always give fully reduced outputs. In the case of ML-KEM, data modulo q = 3,329 is typically stored in signed 16-bit integers. When dealing with lazy arithmetic across the numerous arithmetic routines in ML-KEM, it is therefore essential to track the worst-case bounds of the data and insert modular reductions where those bounds would exceed the limits of 16-bit integers. Small mistakes in this domain can evade testing — because average bounds tend to be much smaller than worst-case bounds — and then randomly surface in production. Tracking buffer bounds and especially arithmetic bounds is time consuming and error prone: for example, weakening the output bounds of a low-level arithmetic function might lead to a rare arithmetic overflow in an entirely different function. Checking this by hand not only requires meticulous documentation and skilled auditors but also slows down development. In mlkem-native, we use a tool called the C Bounded Model Checker (CBMC) to automatically verify memory safety and type safety at the C level: for every function, we add machine- and human-readable contracts to the source code to specify the bounds of buffers and arithmetic data, and we have CBMC automatically verify that, with respect to those bounds, no buffer overflow or arithmetic overflow can happen. Let’s look at a simple example of modular reduction: Focusing on the relevant parts one at a time: First, note the __contract__( ... ) . Slightly simplified, the memory_no_alias and memory_slice lines specify which memory the code can read and write; this relates to memory safety. The ensures(array_bound(...)) clause relates to type safety: it specifies that the function will guarantee that upon return, the data is within the interval [0, 1, …, q). In the proof, you see the __loop__(invariant(...)), specifying how the loop gradually establishes this bound: in the ith iteration, it holds up to the ith coefficient. Finally, the implementation effectively composes mlk_barrett_reduce and mlk_scalar_signed_to_unsigned_q. CBMC does not look inside these but replaces them with their contracts: You can see that mlk_barrett_reduce first establishes a symmetric output interval (-q/2, …, q/2), and then mlk_scalar_signed_to_unsigned_q maps it to [0,1, …, q). In this instance, it is easy to confirm by eye that the specifications line up in the desired way, but for more complex examples, this is less obvious. Either way, CBMC checks it for us automatically. Going fast, staying safe The CBMC proofs described above establish memory safety and type safety for mlkem-native's C code. However, the most performance-critical parts of mlkem-native — the Keccak permutation and number theoretic transform — are implemented in hand-optimized assembly for AArch64 and x86_64. To gain assurance for the assembly implementations in mlkem-native while maintaining high performance, we use three components: SLOTHY, an assembly superoptimizer; HOL Light, a theorem prover; and s2n-bignum, a verification infrastructure for assembly built on HOL Light. Together, they enable a workflow where developers write clean, maintainable assembly, while deployed code achieves peak performance with formal guarantees of correctness. Writing high-performance assembly by hand creates a fundamental tension: clean, auditable code that clearly expresses the computation is slow, while fast code is dense, microarchitecture specific, and difficult to maintain. SLOTHY resolves this tension by automating microarchitecture-specific optimizations: it converts an assembly program into a constraint satisfaction problem, finds optimal instruction schedules and register allocations using a constraint solver, and outputs optimized assembly. Developers write clean code emphasizing the logic of the computation, and SLOTHY generates the fast code. We prove functional correctness for all AArch64 and x86_64 assembly routines using HOL Light and s2n-bignum. Where SLOTHY is used, the proofs are written to be agnostic to the specific instruction ordering and register allocation; we can therefore reoptimize the code for a specific microarchitecture without having to adjust the proofs. This “post-hoc” verification approach establishes the mathematical correctness of the computation represented by the assembly regardless of how it came about; in particular, SLOTHY is removed from the trusted computing base. Keeping it honest Formal verification is never absolute. Every proof links formal objects — specifications and models — to informal, real-world requirements and systems, and these links introduce gaps. Does the formal specification capture what we actually need? Does the formal model faithfully reflect the real system? Is the proof infrastructure itself sound? Earning and maintaining customer trust requires being transparent about these limits. We therefore developed and published a document titled SOUNDNESS.md, where we map out what is proved in mlkem-native, what is assumed, and where the residual risks lie — from the fidelity of the hardware models used in HOL Light proofs, to the larger trusted computing base of CBMC, to the manual bridge between the two verification stacks. For each gap, we describe mitigations in place and outline future work. Our goal is not to claim perfection but to earn trust through transparency. We encourage the community to read SOUNDNESS.md critically, challenge our assumptions, and help us close the remaining gaps. Getting on the road Mlkem-native is integrated into AWS-LC, Amazon's open-source cryptographic library, which underpins secure communication across AWS services. The integration uses an automated importer that pulls mlkem-native source code directly from the upstream repository, ensuring that AWS-LC stays synchronized with the latest verified implementation. The integration is designed for minimal friction: mlkem-native's modular architecture allows AWS-LC to import the core ML-KEM logic while providing its own implementations of platform-specific components. For example, AWS-LC maps mlkem-native's cryptographic primitives to its existing FIPS-202 (SHA-3) implementation, uses AWS-LC's random-number generation and memory zeroization functions, and enables FIPS-mode features like pairwise consistency tests when required. Enabling this is a thin compatibility layer that bridges mlkem-native's API to AWS-LC's infrastructure without modifying the verified code. Critically, the CBMC contracts that prove memory safety and type safety are preserved in the imported source code. While the preprocessor removes them from compiled binaries, they remain in the source as machine-checkable documentation of the code's guarantees — a form of "living proof" that travels with the implementation. Moreover, because both mlkem-native and AWS-LC are open source and permissively licensed, their benefits extend beyond AWS. Anyone can integrate mlkem-native into their systems and gain the same combination of performance and assurance. The formal verification artifacts — CBMC contracts and HOL Light proofs — are part of the repository, all tools involved are open source, and scripts are provided for setup and proof checking, inviting an independent validation of our security claims. Impact The development of mlkem-native demonstrates that the three goals of cryptographic engineering — security, performance, and maintainability — are not in conflict when automated reasoning is applied systematically. CBMC freed us from manually tracking bounds through complex arithmetic, catching errors that would evade testing and surface randomly in production. The annotations stay in the source code as machine-checkable documentation, making the code simultaneously more maintainable and more secure. HOL Light and s2n-bignum allowed us to deploy aggressive assembly optimizations with mathematical certainty of correctness. SLOTHY let us write clean, auditable code while achieving peak performance for specific microarchitectures. And because the proofs are written to be optimization agnostic, we can retarget the code without redoing the verification. The result is an implementation that is simultaneously more secure, faster, and easier to maintain than what traditional development could achieve. We didn't compromise between customer security, customer experience, and our ability to innovate: automated reasoning delivered all three. AWS-LC-FIPS releasePlatformOperation3.14.0Ratioc7iKeygen30899651462.1Encaps30623612332.0Decaps25141515452.0c7gKeygen29617711342.4Encaps28482668742.3Decaps23919647652.3Performance impact of switching from the ML-KEM reference implementation to mlkem-native in Amazon’s cryptography library AWS-LC. ML-KEM-768 performance is measured on c7i and c7g EC2 instances. The numbers represent operations per second (higher is better). The baseline is an AWS-LC-FIPS 3.1 release that contains the ML-KEM C reference implementation. The AWS-LC-FIPS 4 release is built with mlkem-native. The platforms are c7i with Intel(R) Xeon(R) Platinum 8488C and c7g with Graviton 3 processor. Acknowledgments We thank our colleague John Harrison, senior principal applied scientist at the Automated Reasoning Group, for providing the bulk of the AArch64 assembly proofs in HOL Light and for maintaining the HOL Light interactive theorem prover and the s2n-bignum verification infrastructure. Mlkem-native is a collaborative effort involving not only AWS but many members of the open-source community. Foremost, we thank our co-maintainer Matthias Kannwischer from zeroRISC, who started mlkem-native with us and has since been instrumental in the success of the project.

Harshita Arora Joins YC as General Partner

✇Y Combinator Blog
By: Garry Tan
6 April 2026 at 16:00
Harshita Arora Joins YC as General Partner

We're thrilled to announce that Harshita Arora is joining Y Combinator as a General Partner.

Harshita has been a Visiting Partner at YC since the Summer 2025 batch, making her the youngest visiting partner in YC's history.

Harshita discovered coding at 13, dropped out of school at 15 to pursue it full-time, and by 16 had built Crypto Price Tracker, a crypto portfolio management app that was featured by Apple, which was subsequently acquired, and earned her India's Bal Shakti Puraskar, one of the country's highest honors for young achievers. She then received an O-1 visa, moved to San Francisco, and co-founded AtoB (YC S20).

Harshita and her co-founder came into YC with an idea that got killed by Covid, and with zero background in trucking or payments, they spent weeks visiting truck stops until they found the idea that would become AtoB. Today, AtoB is a Series-C stage company building financial infrastructure for the trucking industry. Often described as "Stripe for Trucking," it offers fleet cards, instant payouts, and modern financial tools, serving over 30,000 fleets across the US.

As a General Partner, Harshita will work directly with YC founders at every stage of their companies. She brings deep fintech and infrastructure experience, a founder's instinct for product, and the perspective of someone who's been building companies since she was a teenager.

We're super excited to have her on the team. Welcome, Harshita!

Harshita Arora Joins YC as General Partner

Components of A Coding Agent

✇Ahead of AI
By: Sebastian Raschka · PhD
4 April 2026 at 11:45

In this article, I want to cover the overall design of coding agents and agent harnesses: what they are, how they work, and how the different pieces fit together in practice. Readers of my Build a Large Language Model (From Scratch) and Build a Large Reasoning Model (From Scratch) books often ask about agents, so I thought it would be useful to write a reference I can point to.

More generally, agents have become an important topic because much of the recent progress in practical LLM systems is not just about better models, but about how we use them. In many real-world applications, the surrounding system, such as tool use, context management, and memory, plays as much of a role as the model itself. This also helps explain why systems like Claude Code or Codex can feel significantly more capable than the same models used in a plain chat interface.

In this article, I lay out six of the main building blocks of a coding agent.

Claude Code, Codex CLI, and Other Coding Agents

You are probably familiar with Claude Code or the Codex CLI, but just to set the stage, they are essentially agentic coding tools that wrap an LLM in an application layer, a so-called agentic harness, to be more convenient and better-performing for coding tasks.

Figure 1: Claude Code CLI, Codex CLI, and my Mini Coding Agent.

Coding agents are engineered for software work where the notable parts are not only the model choice but the surrounding system, including repo context, tool design, prompt-cache stability, memory, and long-session continuity.

That distinction matters because when we talk about the coding capabilities of LLMs, people often collapse the model, the reasoning behavior, and the agent product into one thing. But before getting into the coding agent specifics, let me briefly provide a bit more context on the difference between the broader concepts, the LLMs, reasoning models, and agents.

On The Relationship Between LLMs, Reasoning Models, and Agents

An LLM is the core next-token model. A reasoning model is still an LLM, but usually one that was trained and/or prompted to spend more inference-time compute on intermediate reasoning, verification, or search over candidate answers.

An agent is a layer on top, which can be understood as a control loop around the model. Typically, given a goal, the agent layer (or harness) decides what to inspect next, which tools to call, how to update its state, and when to stop, etc.

Roughly, we can think about the relationship as this: the LLM is the engine, a reasoning model is a beefed-up engine (more powerful, but more expensive to use), and an agent harness helps us the model. The analogy is not perfect, because we can also use conventional and reasoning LLMs as standalone models (in a chat UI or Python session), but I hope it conveys the main point.

Figure 2: The relationship between conventional LLM, reasoning LLM (or reasoning model), and an LLM wrapped in an agent harness.

In other words, the agent is the system that repeatedly calls the model inside an environment.

So, in short, we can summarize it like this:

  • LLM: the raw model

  • Reasoning model: an LLM optimized to output intermediate reasoning traces and to verify itself more

  • Agent: a loop that uses a model plus tools, memory, and environment feedback

  • Agent harness: the software scaffold around an agent that manages context, tool use, prompts, state, and control flow

  • Coding harness: a special case of an agent harness; i.e., a task-specific harness for software engineering that manages code context, tools, execution, and iterative feedback

As listed above, in the context of agents and coding tools, we also have the two popular terms agent harness and (agentic) coding harness. A coding harness is the software scaffold around a model that helps it write and edit code effectively. And an agent harness is a bit broader and not specific to coding (e.g., think of OpenClaw). Codex and Claude Code can be considered coding harnesses.

Anyways, A better LLM provides a better foundation for a reasoning model (which involves additional training), and a harness gets more out of this reasoning model.

Sure, LLMs and reasoning models are also capable of solving coding tasks by themselves (without a harness), but coding work is only partly about next-token generation. A lot of it is about repo navigation, search, function lookup, diff application, test execution, error inspection, and keeping all the relevant information in context. (Coders may know that this is hard mental work, which is why we don’t like to be disrupted during coding sessions :)).

Figure 3. A coding harness combines three layers: the model family, an agent loop, and runtime supports. The model provides the “engine”, the agent loop drives iterative problem solving, and the runtime supports provide the plumbing. Within the loop, “observe” collects information from the environment, “inspect” analyzes that information, “choose” selects the next step, and “act” executes it.

The takeaway here is that a good coding harness can make a reasoning and a non-reasoning model feel much stronger than it does in a plain chat box, because it helps with context management and more.

The Coding Harness

As mentioned in the previous section, when we say harness, we typically mean the software layer around the model that assembles prompts, exposes tools, tracks file state, applies edits, runs commands, manages permissions, caches stable prefixes, stores memory, and many more.

Today, when using LLMs, this layer shapes most of the user experience compared to prompting the model directly or using web chat UI (which is closer to “chat with uploaded files”).

Since, in my view, the vanilla versions of LLMs nowadays have very similar capabilities (e.g., the vanilla versions of GPT-5.4, Opus 4.6, and GLM-5 or so), the harness can often be the distinguishing factor that makes one LLM work better than another.

This is speculative, but I suspect that if we dropped one of the latest, most capable open-weight LLMs, such as GLM-5, into a similar harness, it could likely perform on par with GPT-5.4 in Codex or Claude Opus 4.6 in Claude Code. That said, some harness-specific post-training is usually beneficial. For example, OpenAI historically maintained separate GPT-5.3 and GPT-5.3-Codex variants.

In the next section, I want to go more into the specifics and discuss the core components of a coding harness using my Mini Coding Agent: https://github.com/rasbt/mini-coding-agent.

Figure 4: Main harness features of a coding agent / coding harness that will be discussed in the following sections.

By the way, in this article, I use the terms “coding agent” and “coding harness” somewhat interchangeably for simplicity. (Strictly speaking, the agent is the model-driven decision-making loop, while the harness is the surrounding software scaffold that provides context, tools, and execution support.)

Figure 5: Minimal but fully working, from-scratch Mini Coding Agent (implemented in pure Python)

Anyways, below are six main components of coding agents. You can check out the source code of my minimal but fully working, from-scratch Mini Coding Agent (implemented in pure Python), for more concrete code examples. The code annotates the six components discussed below via code comments:

##############################
#### Six Agent Components ####
##############################
# 1) Live Repo Context -> WorkspaceContext
# 2) Prompt Shape And Cache Reuse -> build_prefix, memory_text, prompt
# 3) Structured Tools, Validation, And Permissions -> build_tools, run_tool, validate_tool, approve, parse, path, tool_*
# 4) Context Reduction And Output Management -> clip, history_text
# 5) Transcripts, Memory, And Resumption -> SessionStore, record, note_tool, ask, reset
# 6) Delegation And Bounded Subagents -> tool_delegate

1. Live Repo Context

This is maybe the most obvious component, but it is also one of the most important ones.

When a user says “fix the tests” or “implement xyz,” the model should know whether it is inside a Git repo, what branch it is on, which project documents might contain instructions, and so on.

That’s because those details often change or affect what the correct action is. For example, “Fix the tests” is not a self-contained instruction. If the agent sees AGENTS.md or a project README, it may learn which test command to run, etc. If it knows the repo root and layout, it can look in the right places instead of guessing.

Also, the git branch, status, and commits can help provide more context about what changes are currently in progress and where to focus.

Figure 6: The agent harness first builds a small workspace summary that gets combined with the user request for additional project context.

The takeaway is that the coding agent collects info (”stable facts” as a workspace summary) upfront before doing any work, so that it’s is not starting from zero, without context, on every prompt.

2. Prompt Shape And Cache Reuse

Once the agent has a repo view, the next question is how to feed that information to the model. The previous figure showed a simplified view of this (“Combined prompt: prefix + request”), but in practice, it would be relatively wasteful to combine and re-process the workspace summary on every user query.

I.e., coding sessions are repetitive, and the agent rules usually stay the same. The tool descriptions usually stay the same, too. And even the workspace summary usually stays (mostly) the same. The main changes are usually the latest user request, the recent transcript, and maybe the short-term memory.

“Smart” runtimes don’t rebuild everything as one giant undifferentiated prompt on every turn, as illustrated in the figure below.

Figure 7: The agent harness builds a stable prompt prefix, adds the changing session state, and then feeds that combined prompt to the model.

The main difference from section 1 is that section 1 was about gathering repo facts. Here, we are now interested in packaging and caching those facts efficiently for repeated model calls.

The “stable” “Stable prompt prefix” means that the information contained there doesn’t change too much. It usually contains the general instructions, tool descriptions, and the workspace summary. We don’t want to waste compute on rebuilding it from scratch in each interaction if nothing important has changed.

The other components are updated more frequently (usually each turn). This includes short-term memory, the recent transcript, and the newest user request.

In short, the caching aspect for the “Stable prompt prefix” is simply that a smart runtime tries to reuse that part.

3. Tool Access and Use

Tool access and tool use are where it starts to feel less like chat and more like an agent.

A plain model can suggest commands in prose, but an LLM in a coding harness should do something narrower and more useful and be actually able to execute the command and retrieve the results (versus us calling the command manually and pasting the results back into the chat).

But instead of letting the model improvise arbitrary syntax, the harness usually provides a pre-defined list of allowed and named tools with clear inputs and clear boundaries. (But of course, something like Python subprocess.call can be part of this so that the agent could also execute an arbitrary wide list of shell commands.)

The tool-use flow is illustrated in the figure below.

Figure 8: The model emits a structured action, the harness validates it, optionally asks for approval, executes it, and feeds the bounded result back into the loop.

To illustrate this, below is an example of how this usually looks to the user using my Mini Coding Agent. (This is not as pretty as Claude Code or Codex because it is very minimal and uses plain Python without any external dependencies.)

Figure 9: Illustration of a tool call approval request in the Mini Coding Agent.

Here, the model has to choose an action that the harness recognizes, like list files, read a file, search, run a shell command, write a file, etc. It also has to provide arguments in a shape that the harness can check.

So when the model asks to do something, the runtime can stop and run programmatic checks like

  • “Is this a known tool?”,

  • “Are the arguments valid?”,

  • “Does this need user approval?”

  • “Is the requested path even inside the workspace?”

Only after those checks pass does anything actually run.

While running coding agents, of course, carries some risk, the harness checks also improve reliability because the model doesn’t execute totally arbitrary commands.

Also, besides rejecting malformed actions and approval gating, file access can be kept inside the repo by checking file paths.

In a sense, the harness is giving the model less freedom, but it also improves the usability at the same time.

4. Minimizing Context Bloat

Context bloat is not a unique problem of coding agents but an issue for LLMs in general. Sure, LLMs are supporting longer and longer contexts these days (and I recently wrote about the attention variants that make it computationally more feasible), but long contexts are still expensive and can also introduce additional noise (if there is a lot of irrelevant info).

Coding agents are even more susceptible to context bloat than regular LLMs during multi-turn chats, because of repeated file reads, lengthy tool outputs, logs, etc.

If the runtime keeps all of that at full fidelity, it will run out of available context tokens pretty quickly. So, a good coding harness is usually pretty sophisticated about handling context bloat beyond just cutting or summarizing information like regular chat UIs.

Conceptually, the context compaction in coding agents might work as summarized in the figure below. Specifically, we are zooming a bit further into the clip (step 6) part of Figure 8 in the previous section.

Figure 10: Large outputs are clipped, older reads are deduplicated, and the transcript is compressed before it goes back into the prompt.

A minimal harness uses at least two compaction strategies to manage that problem.

The first is clipping, which shortens long document snippets, large tool outputs, memory notes, and transcript entries. In other words, it prevents any one piece of text from taking over the prompt budget just because it happened to be verbose.

The second strategy is transcript reduction or summarization, which turns the full session history (more on that in the next section) into a smaller promptable summary.

A key trick here is to keep recent events richer because they are more likely to matter for the current step. And we compress older events more aggressively because they are likely less relevant.

Additionally, we also deduplicate older file reads so the model does not keep seeing the same file content over and over again just because it was read multiple times earlier in the session.

Overall, I think this is one of the underrated, boring parts of good coding-agent design. A lot of apparent “model quality” is really context quality.

5. Structured Session Memory

In practice, all these 6 core concepts covered here are highly intertwined, and the different sections and figures cover them with different focuses or zoom levels. In the previous section, we covered prompt-time use of history and how we build a compact transcript. The question there is: how much of the past should go back into the model on the next turn? So the emphasis is compression, clipping, deduplication, and recency.

Now, this section, structured session memory, is about the storage-time structure of history. The question here is: what does the agent keep over time as a permanent record? So the emphasis is that the runtime keeps a fuller transcript as a durable state, alongside a lighter memory layer that is smaller and gets modified and compacted rather than just appended to.

To summarize, a coding agent separates state into (at least) two layers:

  • working memory: the small, distilled state the agent keeps explicitly

  • a full transcript: this covers all the user requests, tool outputs, and LLM responses

Figure 11: New events get appended to a full transcript and summarized in a working memory. The session files on disk are usually stored as JSON files.

The figure above illustrates the two main session files, the full transcript and the working memory, that usually get stored as JSON files on disk. As mentioned before, the full transcript stores the whole history, and it’s resumable if we close the agent. The working memory is more of a distilled version with the currently most important info, which is somewhat related to the compact transcript.

But the compact transcript and working memory have slightly different jobs. The compact transcript is for prompt reconstruction. Its job is to give the model a compressed view of recent history so it can continue the conversation without seeing the full transcript every turn. The working memory is more meant for task continuity. Its job is to keep a small, explicitly maintained summary of what matters across turns, things like the current task, important files, and recent notes.

Following step 4 in the figure above, the latest user request, together with the LLM response and tool output, would then be recorded as a “new event” in both the full transcript and working memory, in the next round, which is not shown to reduce clutter in the figure above.

6. Delegation With (Bounded) Subagents

Once an agent has tools and state, one of the next useful capabilities is delegation.

The reason is that it allows us to parallelize certain work into subtasks via subagents and speed up the main task. For example, the main agent may be in the middle of one task and still need a side answer, for example, which file defines a symbol, what a config says, or why a test is failing. It is useful to split that off into a bounded subtask instead of forcing one loop to carry every thread of work at once.

(In my mini coding agent, the implementation is simpler, and the child still runs synchronously, but the underlying idea is the same.)

A subagent is only useful if it inherits enough context to do real work. But if we don’t restrict it, we now have multiple agents duplicating work, touching the same files, or spawning more subagents, and so on.

So the tricky design problem is not just how to spawn a subagent but also how to bind one :).

Figure 12: The subagent inherits enough context to be useful, but it runs inside tighter boundaries than the main agent.

The trick here is that the subagent inherits enough context to be useful, but also has it constrained (for example, read-only and restricted in recursion depth)

Claude Code has supported subagents for a long time, and Codex added them more recently. Codex does not generally force subagents into read-only mode. Instead, they usually inherit much of the main agent’s sandbox and approval setup. So, the boundary is more about task scoping, context, and depth.

Components Summary

The section above tried to cover the main components of coding agents. As mentioned before, they are more or less deeply intertwined in their implementation. However, I hope that covering them one by one helps with the overall mental model of how coding harnesses work, and why they can make the LLM more useful compared to simple multi-turn chats.

Figure 13: Six main features of a coding harness discussed in previous sections.

If you are interested in seeing these implemented in clean, minimalist Python code, you may like my Mini Coding Agent.

How Does This Compare To OpenClaw?

OpenClaw may be an interesting comparison, but it is not quite the same kind of system.

OpenClaw is more like a local, general agent platform that can also code, rather than being a specialized (terminal) coding assistant.

There are still several overlaps with a coding harness:

  • it uses prompt and instruction files in the workspace, such as AGENTS.md, SOUL.md, and TOOLS.md

  • it keeps JSONL session files and includes transcript compaction and session management

  • it can spawn helper sessions and subagents

  • etc.

However, as mentioned above, the emphasis is different. Coding agents are optimized for a person working in a repository and asking a coding assistant to inspect files, edit code, and run local tools efficiently. OpenClaw is more optimized for running many long-lived local agents across chats, channels, and workspaces, with coding as one important workload among several others.

I am excited to share that I finished writing Build A Reasoning Model (From Scratch) and all chapters are in early access yet. The publisher is currently working on the layouts, and it should be available this summer.

This is probably my most ambitious book so far. I spent about 1.5 years writing it, and a large number of experiments went into it. It is also probably the book I worked hardest on in terms of time, effort, and polish, and I hope you’ll enjoy it.

Build a Reasoning Model (From Scratch) on Manning and Amazon.

The main topics are

  • evaluating reasoning models

  • inference-time scaling

  • self-refinement

  • reinforcement learning

  • distillation

There is a lot of discussion around “reasoning” in LLMs, and I think the best way to understand what it really means in the context of LLMs is to implement one from scratch!

Gemma 4 and what makes an open model succeed

✇Interconnects
By: Nathan Lambert
3 April 2026 at 16:57

Having written a lot of model release blog posts, there’s something much harder about reviewing open models when they drop relative to closed models, especially in 2026. In recent years, there were so few open models, so when Llama 3 was released most people were still doing research on Llama 2 and super happy to get an update. When Qwen 3 was released, the Llama 4 fiasco had just gone down, and a whole research community was emerging to study RL on Qwen 2.5 — it was a no brainer to upgrade.

Today, when an open model releases, it’s competing with Qwen 3.5, Kimi K2.5, GLM 5, MiniMax M2.5, GPT-OSS, Arcee Large, Nemotron 3, Olmo 3, and others. The space is populated, but still feels full of hidden opportunity. The potential of open models feels like a dark matter, a potential we know is huge, but few clear recipes and examples for how to unlock it are out there. Agentic AI, OpenClaw, and everything brewing in that space is going to spur mass experimentation in open models to complement the likes of Claude and Codex, not replace them.

Especially with open models, the benchmarks at release are an extremely incomplete story. In some ways this is exciting, as new open models have a much higher variance and ability to surprise, but it also points at some structural reasons that make building businesses and great AI experiences around open models harder than the closed alternatives. When a new Claude Opus or GPT drops, spending a few hours with them in my agentic workflows is genuinely a good vibe test. For open models, putting them through this test is a category error.

Something else to be said about open models in the era of agents is that they get out of the debate of integration, harnesses, and tools and let us see close to the ground on what exactly is the ability of just a model. Of course, we can’t test some things like search abilities without some tool, but being able to measure exactly the pace of progress of the model alone is a welcome simplification to a systematically opaque AI space.

Share

The list of factors I’d use to assess a new open-weight model I’m considering investing in includes:

  1. Model performance (and size) — how this model performs on benchmarks I care about and how it compares to other models of a similar size.

  2. Country of origin — some businesses care deeply about provenance, and if a model was built in China or not.

  3. Model license — if a model needs legal approval for use, uptake will be slower at mid-sized and large companies.

  4. Tooling at release — many models release with half-broken, or at least substantially slower, implementations in popular software like vLLM, Transformers, SGLANG, etc due to pushing the envelope of architectures or tools.

  5. Model fine-tunability — how easy or hard it is to modify the given model to your use-case when you actually try and use it.

The core problem is that some of these are immediately available at release, e.g. general performance, license, origin, etc. but others such as tooling take day(s) to week(s) to stabilize, and others are open research questions — with no group systematically monitoring fine-tunability.

In the early era of open models, the days of Llama 2 or 3 and Qwen pre v3.5, the architectures were fairly simple and the models tended to work out of the box. Some of this was due to the extremely hard work of the Llama, Qwen, Mistral, etc. developer teams. Some is due to the new models being genuinely harder to work with. When it comes to something like Qwen 3.5 or Nemotron 3, with hybrid models (either gated delta net or mamba layers), the tooling is very rough at release. Things you would expect to “just work” often don’t.

I’ve been following this area closely since we released Olmo Hybrid with a similar architecture, and Qwen 3.5 is just starting to work well in the various open-source tools that need to all play nice together for RL research. That’s 1.5 months after the release date! This is just to start really investing more into understanding the behavior of the models. Of course, others started working on these models sooner by investing more engineering resources or relying on partially closed software. The fully open and distributed ecosystem takes a long time to get going on some new models.

All of this is lead-in for the most important question for open models — how easy is it to adapt to specific use-cases? This is a different problem for different model sizes. Large MoE open-weight models may be used by entities like Cursor who need complex capabilities in their domain, e.g. Composer 2 trained on Kimi K2.5. Other applications can be built on much smaller models, such as Chroma’s Context-1 model for agentic search, built on GPT-OSS 20B.

The question of “which models are fine-tunable” is largely background knowledge known by engineers across the industry. There should be a thriving research area here to support the open ecosystem model. The first step is to understand characteristics of different base and post-trained models to understand what they look like. The second step is to tune pretraining recipes for open models so they’re more flexible.

Interconnects AI is a reader-supported publication. Consider becoming a subscriber.

For The ATOM Project and other Interconnects endeavors, we’ve put in substantial effort to measuring adoption trends in the open ecosystem. Everything takes a long time to unfold after a model is first publicly available — and adaptability is why. What we know for sure now, when Qwen has been going from strength to strength with its releases, is that technical staff across the industry has gotten comfortable working with Qwen models. Countless research methods and datasets were made to work with Qwen. It’ll take patience for any other model family to get to this point — a patience I’m not sure many open model builders have.

This takes us to Gemma 4, Google’s latest open models. Gemma 3 was released more than a year ago, in March of 2025, and is a bit underrated. Gemma 4 comes in 4 sizes for now, with a bigger, MoE model of over 100B total parameters rumored but not released yet. The models we have today come in sizes of ~5B dense, 8B dense, 26B total 4B active MoE, and 31B dense.

I’m most excited that they’re finally adopting a standard Apache 2.0 open source license. This’ll massively boost adoption. The standard of better licenses for strong open-weight LLMs was set by mostly Chinese open model labs in the last 1-2 years, and now U.S. companies are following suit. I will personally be so happy if the horrible Llama licenses and Gemma terms of service were an ~18-month transient dynamic of the industry being nervous about releasing strong open models.

The Gemma 4 scores look very solid, the small models have incredible benchmark scores (especially in general domains like LMArena) and the 31B model rivals the recent Qwen 3.5 27B, which is the leading member of that class. The ~30B size range is an important one, as it’s accessible both to researchers and to enterprises looking to deploy the model in real use-cases. Where the 7B model scale is the default for tinkering and research, a 30B model is the default for seeing if an open model can unlock substantial value in your specific workflow — a good mix of intelligence, low price, tractability for downstream training, etc.

Source: Sebastian Raschka, Ahead of AI

This takes us back to the above adoption criteria I mentioned for open models and the bigger question — do I think Gemma 4 will be an overwhelming success? Previous Gemma models have been plagued by tooling issues and poorer performance when being finetuned.

Gemma 4’s success is going to be entirely determined by ease of use, to a point where a 5-10% swing on benchmarks wouldn’t matter at all. It’s strong enough, small enough, with the right license, and from the U.S., so many companies are going to slot it in.

I’m cautiously optimistic that Gemma 4 is going to work better here. Winds are shifting for open models built in America. We saw GPT-OSS go through a bumpy launch to become an overwhelming success. There’s a collective energy around the likes of Reflection, Arcee, Nemotron, Gemma, Olmo, and peers that show substantial demand for building new stacks around open models. There’s capital to be spent on AI stacks across the economy by those who want more ownership of everything, including the model.

After launching The ATOM Project 240 days ago, the conversation is shifting into the next stage. Summer of 2025 was a crisis moment where the U.S. AI scene realized it can’t wait and figure out open models after building AGI. The two markets will capture different areas and proceed in parallel. Now that more companies in the U.S. are releasing strong models, we need to improve the ecosystem so that these models are easy to use, understand, and build value around. It’s the hard work to build another inflection point in these adoption plots I’ve been updating consistently, but that’s the work to be done. Join me in it.

More data coming soon! Here’s a sneak peek:

Received — 2 April 2026 ⏭ ai/automation

Improving quality and robustness in LLM-based text-to-speech systems

✇Amazon Science homepage
1 April 2026 at 18:13
Text-to-speech models based on large language models (LLMs) have gotten very good at producing natural-sounding speech, even in voices cloned from short audio files. But some problems with these models still persist. One is accent leakage in polyglot text to speech. It should be possible to transfer a voice recorded in English to French, German, or Spanish with the correct accent and without loss of voice identity. But with most systems, the reference speaker's native accent leaks into the target language, or the target language's accent overwrites characteristics of the speaker’s voice. Expressiveness is another challenge, including the laughs, sighs, hesitations, and other indications of emotion that make speech engaging. And then there’s reliability. Unlike traditional text-to-speech (TTS) systems, LLM-based systems are autoregressive, meaning they generate speech tokens one at a time, without explicitly modeling duration. This can cause hallucinated repetitions, unexpected cutoffs, and inconsistent pronunciation. At Amazon, we're working to address all these issues. Mitigating accent leakage in polyglot TTS We use a locale-specific data augmentation approach to address the problem of accent leakage. Specifically, we use low-rank adaptation (LoRA) to fine-tune our polyglot models on data that is heavily weighted toward target locales. This also allows us to do accent-free polyglot voice cloning: the cloned voice speaks the target language with native-like pronunciation but without loss of speaker identity. Improving expressiveness We use classifier-free guidance (CFG) to generate synthetic reference audio samples with enhanced expressiveness. Using these as conditioning during inference pushes the model toward more expressive prosodic styles. Originally developed for diffusion modeling, CFG controls how strongly generation follows conditioning. CFG-based reference samples decouple speaker identity from accent, teaching the model to preserve voice characteristics while adopting native pronunciation in the target language. This allows us to scale a small number of recorded voices to many new locales and languages, while increasing expressiveness. Scored according to MUSHRA (multiple stimuli with hidden reference and anchor) listening tests, the quality of our models’ polyglot outputs across nine locales spanning English, French, Italian, German, and Spanish improved 5% to 20% over those of our previous model family. LocaleImprovement over baselineUS-English+12.43%Southern US-English+20.05%Great Britain-English+5.97%Australia-English+5.50%US-Spanish+11.78%Spain-Spanish+13.23%France-French+8.44%Germany-German+14.12%Italy-Italian+9.80%Robustness Traditional TTS had failure modes, but hallucination and random truncation weren't chief among them. LLM-based TTS can generate confident-sounding speech that doesn't match the input, and it will sometimes stop mid-sentence. Chain-of-thought for autoregressive TTS Traditional TTS pipelines have explicit stages: grapheme-to-phoneme conversion, duration prediction, and acoustic generation. More recent, non-autoregressive end-to-end models like FastSpeech predict durations explicitly before speech generation. LLM-based TTS takes an alternate approach. Duration emerges implicitly from autoregressive generation. There's no explicit plan for how long the utterance should be or how long each phoneme should take. This is why these models hallucinate (keep generating past the intended content) or truncate (stop too early). To address this problem, we add chain-of-thought reasoning to the model: before generating speech tokens, the model predicts phoneme sequences and estimates duration (total length and per-phoneme timing). This isn't the same as traditional TTS pipelines. Bolting duration prediction onto an autoregressive architecture is a different problem than building it into a non-autoregressive one, and it has its own challenges. Phoneme prediction enables the model to handle heteronyms ("read," "lead") and unusual names more reliably. Duration prediction gives the model a timing plan, which reduces both hallucination and truncation. These predictions are also useful for debugging, as you can see what the model "thought" it was going to generate before it started generating. Guardrails Our guardrails use the chain-of-thought predictions as checkpoints. We know the expected phoneme count and approximate speech duration before generation starts. After generation, we do a pair of checks: does the output duration match the prediction, and is the output length reasonable given the phoneme count? Large deviations flag likely hallucinations or truncations. When an agent detects problems, it can prompt the TTS system to regenerate with different sampling parameters or fall back to alternative approaches. Data filtering To filter the text data passing to the TTS model, we combine speech-recognition-based metrics with metrics based on the LLM’s attention mechanism. Automatic speech recognition (ASR) catches actual transcription errors. Taken together, the metrics keep data that's genuinely well aligned while preserving expressiveness that ASR-only filtering would discard. On generic long-form text, our full array of techniques reduces critical errors to an average of less than one second per hour, where “critical errors” include hallucinations, cutoffs beyond one word, and mismatches between input text and output speech. Conclusion LLM-based TTS models sound noticeably more natural than traditional systems. However, in our experience, they introduce new failure modes that need to be addressed before they can be deployed reliably in production. We have found that LoRA-based fine tuning addresses the heavy accent leakage observed in polyglot TTS, while classifier-free guidance is a useful tool for improving expressiveness. As for reliability, we find that smart data filtering and chain-of-thought reasoning coupled with guardrails and agentic regeneration can significantly reduce hallucination.
Received — 31 March 2026 ⏭ ai/automation

From Hierarchy to Intelligence

✇Sequoia Capital
By: amoore
31 March 2026 at 15:11

From Hierarchy to Intelligence

By Jack Dorsey and Roelof Botha

At Sequoia, we see that speed is the best predictor of start-up success. Most companies are focused on AI as a productivity enhancer. Few are focused on the potential of AI to change how we work together. Block is showing what it looks like to fundamentally rethink organization design, ultimately harnessing AI to increase speed as a compounding competitive advantage.

Two thousand years before the first corporate org chart, the Roman Army solved a problem that every large organization still faces: how do you coordinate thousands of people across vast distances with limited communication?

Their answer was a nested hierarchy with a consistent span of control at every level. The smallest unit was the contubernium, eight soldiers who shared a tent, equipment, and a mule, led by a decanus. Ten contubernia formed a century of eighty men under a centurion. Six centuries made a cohort. Ten cohorts made a legion of roughly 5,000. At each layer, a named commander held defined authority, aggregated information from below, and relayed decisions from above. The structure (8 → 80 → 480 → 5,000) was an information routing protocol built around a simple human limitation: a leader can effectively manage somewhere between three and eight people. The Romans discovered this through centuries of warfare. Even today, the US Army’s hierarchical chain follows a similar pattern. We now call it “span of control,” and it remains the governing constraint of every large organization on earth.

The next big change came from Prussia. After Napoleon’s army destroyed the Prussian forces at the Battle of Jena in 1806, a group of reformers led by Scharnhorst and Gneisenau rebuilt the military around an uncomfortable truth: you cannot depend on individual genius at the top. You need a system. They created the General Staff, a dedicated class of trained officers whose job was not to fight but to plan operations, process information, and coordinate across units. Scharnhorst intended these staff officers to “support incompetent Generals, providing the talents that might otherwise be wanting among leaders and commanders.” This was middle management before the term existed. Professionals whose purpose was to route information, pre-compute decisions, and maintain alignment across a complex organization. The military also formalized the distinction between “line” and “staff” functions. Line advances the core mission. Staff provides specialized support. Every corporation still uses this vocabulary today.

Military hierarchy entered the business world through the American railroads in the 1840s and 1850s. The U.S. Army lent West Point-trained engineers to private railroad companies, and these officers brought military organizational thinking with them. Staff and line hierarchies, divisional structure, bureaucratic systems of reporting and control: all of it was developed in the military before the railroads adopted it. In the mid-1850s, Daniel McCallum of the New York and Erie Railroad created the world’s first organizational chart to manage a system stretching over 500 miles with thousands of workers. The informal management styles that worked for smaller railroads were failing. Train collisions were killing people. McCallum’s chart formalized the same hierarchical logic the Romans had used: layers of authority, defined reporting lines, structured information flow. It became the blueprint for the modern corporation.

Frederick Taylor (1856-1915), often called the “Father of Scientific Management,” optimized what happened within that hierarchy. Taylor broke work into specialized tasks, assigned them to trained experts, and managed through measurement rather than intuition. This produced the functional pyramid organization – a structure optimized for efficiency within the information routing system that the military had pioneered and the railroads had commercialized.

The first real stress test of functional hierarchy came during World War II. The Manhattan Project required physicists, chemists, engineers, metallurgists, and military officers to work across disciplinary boundaries toward a single objective under extreme secrecy and time pressure. Robert Oppenheimer organized Los Alamos into functional divisions but insisted on open collaboration across them, resisting the military’s instinct to compartmentalize. When the implosion problem became critical in 1944, he reorganized the lab around it, creating cross-functional teams unlike anything in corporate America at the time. It worked, but it was a wartime exception led by a singular figure. The question the postwar business world faced was whether that kind of cross-functional coordination could be made routine.

With the growth and globalization of companies after World War II, the scale limitations of functional design became acute. In 1959, McKinsey’s Gilbert Clee and Alfred di Scipio published “Creating a World Enterprise” in the Harvard Business Review, providing an intellectual framework for a matrix organization that combined functional specialties with divisional units. Under the leadership of Marvin Bower, McKinsey helped companies like Shell and GE implement these principles, balancing central standards with local agility. This became the “professional” or “modern” corporation that propelled the postwar global economy.

Over time, other frameworks emerged to address the complexity, rigidity, and bureaucracy of matrix structures. The McKinsey 7-S framework, developed in the late 1970s by Tom Peters and Robert Waterman, distinguished the “hard Ss” (Strategy, Structure, Systems) from the “soft Ss” (Shared Values, Skills, Staff, Style). The core idea was that structural elements alone were insufficient. Organizational effectiveness required alignment across cultural traits and the human factors that determine whether a strategy actually succeeds.

In more recent decades, technology companies have experimented aggressively with organization structure. Spotify popularized cross-functional squads with short sprint cycles. Zappos attempted Holacracy, eliminating management titles entirely. Valve operated with a flat structure and no formal hierarchy. Each of these experiments revealed something about the limitations of traditional hierarchy, but none solved the underlying problem. Spotify moved back toward conventional management as it scaled. Zappos saw significant attrition. Valve’s model proved difficult to scale beyond a few hundred people. As organizations grow into the thousands, they revert to hierarchical coordination because no alternative information routing mechanism has been powerful enough to replace it.

The constraint is the same one the Romans faced and the Marine Corps rediscovered in World War II: narrowing span of control means adding layers of command, but more layers mean slower information flow. Two thousand years of organizational innovation has been an attempt to work around this tradeoff without breaking it.

So what’s different now?

At Block, we’re questioning the underlying assumption: that organizations have to be hierarchically organized with humans as the coordination mechanism. Instead, we intend to replace what the hierarchy does. Most companies using AI today are giving everyone a copilot, which makes the existing structure work slightly better without changing it. We’re after something different: a company built as an intelligence (or mini-AGI).

We are not the first to try to move beyond traditional hierarchy. Haier’s rendanheyi model, platform organizations, “data-driven” management: these are real attempts at the same problem. What they lacked was a technology capable of actually performing the coordination functions that hierarchy exists to provide. AI is that technology. For the first time, a system can maintain a continuously updated model of an entire business and use it to coordinate work in ways that previously required humans relaying information through layers of management.

For this to work, a company needs two things: a kind of “world model” of its own operations, and a customer signal rich enough to make that model useful.

Block is remote-first. Everything we do creates artifacts. Decisions, discussions, code, designs, plans, problems, and progress all exist as recorded actions. It’s the raw material for a company world model. In a traditional company, a manager’s job is to know what’s happening across their team and relay that context up and down the chain. In a remote-first company where work is already machine-readable, AI can build and maintain that picture continuously. What’s being built, what’s blocked, where resources are allocated, what’s working and what isn’t. That’s the information the hierarchy used to carry. The company world model carries it instead.

But the capability of the system is only as good as the quality of the customer signal feeding it. And money is the most honest signal in the world.

People lie on surveys. They ignore ads. They abandon carts. But when they spend, save, send, borrow, or repay, that’s the truth. Every transaction is a fact about someone’s life. Block sees both sides of millions of these transactions every day, the buyer through Cash App and the seller through Square, plus the operational data from running the merchant’s business. That gives the customer world model something rare: a per-customer, per-merchant understanding of financial reality built from honest signal that compounds. The richer the signal, the better the model. The better the model, the more transactions. The more transactions, the richer the signal.

Together, the company world model and the customer world model form the foundation for a different kind of company. Instead of product teams building predetermined roadmaps, you build four things.

First, capabilities. The atomic financial primitives: payments, lending, card issuance, banking, buy-now-pay-later, payroll, and so on. These are not products. They are building blocks that are hard to acquire and maintain (some have network effects and regulatory permission). They have no UIs of their own. They have reliability, compliance, and performance targets.

Second, a world model. This has two sides. The company world model is how the company understands itself and its own operations, performance, and priorities, replacing the information that used to flow through layers of management. The customer world model is the per-customer, per-merchant, per-market representation built from proprietary transaction data. It starts with raw transaction data today and evolves toward full causal and predictive models over time.

Third, an intelligence layer. This is what composes capabilities into solutions for specific customers at specific moments and delivers them proactively. A restaurant’s cash flow is tightening ahead of a seasonal dip the model has seen before. The intelligence layer composes a short-term loan from the lending capability, adjusts the repayment schedule using the payments capability, and surfaces it to the merchant before they even think to look for financing. A Cash App user’s spending pattern shifts in a way the model associates with a move to a new city. The intelligence layer composes a new direct deposit setup, a Cash App Card with boosted categories for their new neighborhood, and a savings goal calibrated to their updated income. No product manager decided to build either solution. The capabilities existed. The intelligence layer recognized the moment and composed them.

Fourth, interfaces (hardware and software). Square, Cash App, Afterpay, TIDAL, bitkey, proto. These are delivery surfaces through which the intelligence layer delivers composed solutions. They are important, but they are not where the value is created. The value is in the model and the intelligence.

When the intelligence layer tries to compose a solution and can’t because the capability doesn’t exist, that failure signal is the future roadmap. The traditional roadmap, where product managers hypothesize about what to build next, is any company’s ultimate limiting factor. In this model, customer reality generates the backlog directly.

If this is what the company builds, then the question becomes: what do the people do?

The org structure follows from this, and it inverts the traditional picture. In a conventional company, the intelligence is spread throughout the people and the hierarchy routes it. In this model, the intelligence lives in the system. The people are on the edge. The edge is where the action is.

The edge is where the intelligence makes contact with reality. People reach into places the model can’t go yet. They sense things the model can’t perceive: intuition, opinionated direction, cultural context, trust dynamics, the feeling in a room. They make the calls the model shouldn’t make on its own, especially ethical decisions, novel situations, and high-stakes moments where the cost of being wrong is existential. A world model that can’t touch the world is just a database. But the edge doesn’t need layers of management to coordinate it. The world model gives every person at the edge the context they need to act without waiting for information to travel up and down a chain of command.

In practice, this means we normalize down to three roles.

Individual contributors (ICs) who build and operate capabilities, the model, the intelligence layer, and the interfaces. They are deep specialists and experts in a specific layer of the system. The world model provides the context that a manager used to provide, so ICs can make decisions about their layer without waiting to be told what to do.

Directly Responsible Individuals (DRI) who own specific cross-cutting problems or opportunities and customer outcomes. A DRI might own the problem of merchant churn in a specific segment for 90 days, with full authority to pull resources from the world model team, the lending capability team, and the interface team as needed. DRIs may persist on certain problems or move elsewhere to solve new ones.

Player-coaches who combine building with developing people. They replace the traditional manager whose primary job was information routing. A player-coach still writes code or builds models or designs interfaces. They also invest in the growth of the people around them. They don’t spend their days in status meetings, alignment sessions, and priority negotiations. The world model handles alignment. The DRI structure handles strategy and priority. The player-coach handles craft and people.

There is no need for a permanent middle management layer. Everything else the old hierarchy did, the system coordinates, and everyone is empowered, with a role that’s much closer to the work and the customer.

Block is in the early stages of this transition. It will be a difficult one, and parts of it will likely break before they work. We’re writing about it now because we believe every company will eventually need to confront the same question we did: what does your company understand that is genuinely hard to understand, and is that understanding getting deeper every day?

If the answer is nothing, AI is just a cost optimization story. You cut headcount, improve margins for a few quarters, and eventually get absorbed by something smarter. If the answer is deep, AI doesn’t augment your company. It reveals what your company actually is.

Block’s answer is the economic graph: millions of merchants and consumers, both sides of every transaction, financial behavior observed in real time. That understanding compounds every second the system operates. We believe the pattern behind this, a company organized as an intelligence rather than a hierarchy, is significant enough that it will reshape how companies of all kinds operate over the coming years. Block is far enough along to show the idea is more than theory (though, we welcome debate and feedback to pressure test and improve our ideas).

Companies move fast or slow based on information flow. Hierarchy and middle management impede information flow. For two thousand years, from the Roman contubernium to today’s global enterprises, we have had no real alternative. Eight soldiers sharing a tent needed a decanus. Eighty men needed a centurion. Five thousand needed a legate. The question was never whether you needed layers. The question was whether humans were the only option for what those layers do. They aren’t anymore. Block is building what comes next.

Share

Share this via email

The post From Hierarchy to Intelligence appeared first on Sequoia Capital.

Rethinking AI data: From scraping to sustainable and ethical data sharing

✇OECD.AI
By: Marie Langé
31 March 2026 at 11:46
abstract image of data sharing

The AI data paradox

As our daily activities become more digitised, from ordering dinner to receiving medical care, the amount of data produced by humans and machines continues to grow each year.  The internet provides a seemingly limitless flow of accessible data of all formats and natures, from news sites to social media. In early 2026, the internet archive initiative CommonCrawl boasted over 300 billion webpages in its database. Adding to this digital abundance, even larger volumes of data remain underused and locked in organisations’ private databases. Meanwhile, IBM reports that in 2024, the biggest challenge for AI developers was a shortage of high-quality data. This is the AI data paradox: despite an abundance of data globally, AI developers face a scarcity of usable data, with growing expert concerns about a looming data crunch as reported by the OECD (2025).

The new GPAI-associated report, From scraping to ethical data sharing, produced under the VIADUCT initiative, addresses this paradox. Based on 25 interviews and two multistakeholder workshops held in 2025, the report complements the OECD’s Recommendations on Enhancing Access to and Sharing of Data (EASD, 2019) and grounds its analysis in the concrete challenges faced by both data holders and AI developers when sharing and accessing data.

Scraped internet data as a key source for AI training

Data is the cornerstone of modern AI development, from model training to grounding. As online public content continues to grow, it has become a major source of training data for AI models. Initiatives such as CommonCrawl and LAION have harvested, or “scraped”, billions of online pages and images, ranging from news articles and government websites to blogs and social media. These datasets fuel rapid advances in AI tools, but also pose deep challenges.

Figure 1: The AI data value chain: From scraping data for reuse to content to generation

Contemporary AI requires contemporary data sourcing methods

As investment and revenue flow, AI has become a major industry, but data-sourcing methods have not kept pace. Many current AI processes still rely heavily on scraping large amounts of public content, often without permission, proper compensation or quality controls. But this “grab what you can” approach has limits. As the report documents, over 50 copyright and data protection lawsuits have been filed worldwide, while websites are increasingly deploying technical and contractual barriers to prevent scraping. At the same time, the web is increasingly saturated with low-quality material, including AI-generated “slop” and disinformation. Meanwhile, vast amounts of valuable data remain locked away on private servers because concerns about legal risk and confidentiality inhibit sharing.

These quality challenges and legal pressures point to the need for a new approach, one that moves beyond extraction towards mutually beneficial data-sharing arrangements, including commercial and non-commercial agreements as described in the OECD’s Mapping Relevant Data Collection Mechanisms for AI Training report (2025). Instead of relying on a single technical solution, the VIADUCT report presents data sourcing as a systemic challenge at the intersection of law, economics and technology. While data infrastructures have expanded significantly, experience shows that technical capacity alone does not initiate data flows.

Data sharing as a transaction

If not a simple engineering problem, then what is data sharing? At its most basic, data sharing is a transaction between two parties.

For common assets such as treasury bonds, Brent crude oil or soda cans, industry standards, regulations and institutions support transactions and build market trust. By contrast, data is not a standard asset. It is a collection of diverse assets that take different forms, with varying stakeholders and regulatory requirements. Consider two datasets: one with hospital patients’ X-rays, and another with archived news articles. The first dataset contains sensitive personal information protected under the GDPR in Europe and must comply with the principles of confidentiality and consent. News articles in the second dataset are copyrighted works whose owners can prohibit reproduction and opt out of AI training under EU law. These simple examples show that sharing data cannot rely on technology alone but must also consider a dataset’s economic, legal and social contexts and constraints.

Data is not monolithic

Government officials and business leaders often use metaphors like “raw material”, “new oil” and “gold” to describe data. However, contrary to what these metaphors suggest, data is not a uniform resource. In its EASD in the age of AI (2025), the OECD describes data as “recorded information in structured or unstructured formats, including texts, images, sound, and video”, which may also include AI models themselves when training data is memorised. On top of its diversity of shapes and formats, data is also a mosaic of digital assets, each governed by different rules, logic and constraints. Is one dealing with a copyrighted news article? Personal health records? A company’s trade secrets? Government statistics? Open source software code? Understanding this is essential to designing sustainable AI data ecosystems. Each type of data has its own legal guardrails, economic dynamics and technical challenges.

The VIADUCT report classifies data into five governance regimes according to the EU legal framework:

Figure 2: Data governance regimes under EU law

Governance modelData scopeDataset example
Copyrighted contentAll creative works, including texts, images, videos, sounds, software source code and certain databases. Authors have exclusive rights to reproduce, communicate and distribute their works. They can also opt-out of commercial AI processing.  News article dataset, book archive, social media posts, music database
Personal dataAny data or information relating to an identified or identifiable individual (“data subject”). Under EU’s GDPR, a data processing, such as AI training, must be transparent, confidential, minimal and motivated by legal grounds such as data subject consent, or controller’s legitimate interest.  Customer history database, patients’ medical records, mobile phone GPS locations
Trade secretsA dataset which is secret, is safeguarded and holds value due to its secrecy. Companies are protected against unlawful access, and can share trade secrets with third parties under strict safeguarding measures.  Engineering blueprint files, pharmaceutical molecule database, commercial lead database
Public sector dataUnder EU law, public sector bodies must publish their documents for commercial and non-commercial reuse, free from exclusive license and without fee beyond cost compensation.  Texts of law, national statistics, national company registry
Open dataAny data which can be accessed, shared and used by anyone for any purpose, free of charge. In Europe, this may include contents with expired copyrights, government documents, and open-license content19th century books, Wikipedia articles, open-source software code

Three guiding principles for sustainable and responsible approaches to data sharing for AI

In this diverse and complex environment, the report sets out three clear guiding principles that apply to all data types and governance regimes to foster sustainable and ethical data sharing for AI.

Legal compliance is the first principle. Data sharing and downstream use must respect applicable legal frameworks. In Europe, this includes honouring copyright holders’ rights, establishing legal grounds for the use of personal data and protecting confidential trade secrets.

The second is trust. Data holders need assurance that their data will be used only for permitted or legitimate purposes and protected by robust cybersecurity measures. Data consumers, in turn, need confidence that datasets are legitimate, accurate and of high quality.

The third principle is fairness. Data-sharing arrangements should be mutually beneficial, crediting organisations that support AI development and, where appropriate, sharing the benefits.

Figure 3: Ethical data sharing principles and best practices

Constraints for ethical data sharing

These principles sound simple, but applying them in practice is challenging. Exchanging large volumes of data requires expertise, which is often lacking in smaller organisations, and the process is fraught with technical, legal, and economic frictions. Data quality issues are a major source of friction, as errors, inappropriate content or bias can create risks and costs for downstream AI use. Ensuring data holders maintain control of their data after sharing or publishing is essential. This is referred to as digital self-determination. This is the case for personal data, copyrighted content or trade secrets, for which the data holder must often grant permission for each new processing act. EU law imposes strict confidentiality standards for personal data, trade secrets and sensitive government data. Finally, to incentivise data sharing and ensure its sustainability for data holders, implementing appropriate economic models such as cost and value compensation appears to be an essential solution.

Figure 4:  Ethical data sharing constraints

Transitioning to a multidisciplinary and implementation-focused approach

This non-exhaustive list of challenges illustrates the limits of relying only on normative or technical responses to address data-sharing constraints. The report investigates alternative approaches, such as opt-out methods, smart contracts, data attribution and privacy-enhancing technologies.

When it comes to ethical data sharing, moving from Is it possible? to How can we implement it? requires developing actionable tools and recommendations to address challenges. Given their diverse and context-sensitive nature, VIADUCT facilitates dialogue among data holders, AI developers, policymakers and researchers on concrete data-sharing projects and experiments. Ultimately, this exercise seeks to create a better understanding of the challenges for data sharing and promote and test innovative solutions at the crossroads of technology, economics and law.

The post Rethinking AI data: From scraping to sustainable and ethical data sharing appeared first on OECD.AI.

❌