# Brian Wald — Full Content

All posts and musings in markdown, most recent first.


---

# The Next Golden Path Is for Agents

_Published April 24, 2026 · https://brianwald.com/blog/platforms-newest-user-isnt-human_

I recently saw an <a href="https://wheelfront.com/this-alberta-startup-sells-no-tech-tractors-for-half-price/" target="_blank" rel="noopener">Alberta company selling new diesel tractors</a> without emissions electronics or software-locked diagnostics, for about half the price of a similar John Deere. The appeal is simple. A farmer who lives forty miles from the nearest dealer wants a machine they can fix themselves, not one that needs remote diagnostics.

The point is segmentation. John Deere may be protecting a lucrative service lifecycle, but the product direction still reveals a real user split. Some customers want complexity handled for them. Others need enough of the machinery exposed that they can repair it when something breaks. Both are valid depending on the use case.

Enterprise platforms have the same split, and AI is going to add another vector that platform teams will need to account for. Platforms have always segmented users by responsibility, sometimes by design and sometimes by accident: teams that should not own the underlying mechanisms, and teams trusted to work directly with the primitives. Now, a third kind of user has appeared that fits neither path.

That user is the agent. The next platform user is an automated actor executing a task inside a system, with no defined responsibility model behind it. Agents require a path designed for scoped context, temporary authority, typed state, and evidence captured while the work happens. Most platform organizations have not drawn that line yet.

## How platforms accumulate layers

Platforms usually get more complex over time as they try to handle more use cases. For example, post-incident reviews often end up in adding controls or guardrails. Over time, the platform absorbs problems the organization has not addressed elsewhere, often because those problems are too difficult to fix at the source.

Each decision may make the platform safer in isolation, but it also adds overhead. Over time, safety and complexity start to create fragile layers. That trade-off only works if teams want the platform to absorb more of the work. While some do, high-performing teams often prefer a simpler platform that lets them debug issues independently and use support tickets only when necessary.

Even before agents, the result was a platform that treated very different teams like the same user because they needed a "golden path" that would help standardize across teams the best they could.

Some teams rely on the platform because owning the underlying mechanisms is not their job. For them, tuning those mechanisms slows delivery and can increase security risk, so the platform needs to provide telemetry, recovery, security, evidence, and safe defaults. Other teams work closer to the performance edge. They need to remove generalized layers and tune primitives for systems with very specific needs, where extra abstraction gets in the way.

## The portal looks done, delivery still hurts

Portals can create a false sense of confidence by measuring whether teams use the managed path, rather than whether the path actually relieves teams of their workload.

Last quarter, I visited an insurance company where the platform team had rolled out a new internal portal and shared impressive adoption numbers. When I talked to the release engineers on three of their critical systems, I heard a different story. They were still manually editing generated CI pipelines because the templates didn't support their test setup, and change management tickets were still being filled out by hand and pushed to ServiceNow because the automated evidence bundle missed the audit fields their regulator cared about. The portal existed, but the useful parts of the platform could not be recombined in a way that matched how those systems actually shipped, so the work stayed with the teams.

A better test is simple: when a release stops following the golden path, who owns the exception? If the app team still has to stitch it together by hand, the platform has not really absorbed the work.

The alternative approach has its own risks. Expert teams may work directly with primitives and initially move faster, but speed alone does not ensure effective governance. I have observed teams managing their own pipelines and observability stacks until an incident or audit required a comprehensive record of changes, approvals, and evidence. While the data existed, it was dispersed across tools and could not be reviewed end-to-end.

Agents hit the same gap with less to fall back on. Operating a system is not the same as governing it. Human experts have always covered that gap with judgment and institutional memory, especially when the platform did not capture the full story. When the work moves to an agent, that fallback does not exist and it creates high risk.

Usually, the analysis stops at these two examples and lands on a familiar conclusion: segment teams by operational maturity, and accept that some teams will own more of the platform locally than leaders would prefer.

I now think that is the wrong axis. The important question is whether the work is being done by a human team or by agents acting for a specific task.

## The platform's newest user

Debates about golden paths versus custom pipelines in enterprise software are fundamentally about which of these two user groups the platform should serve. This discussion assumes these are the only groups worth designing for.

That assumption is starting to change. Some of the work now lands with agents, and they need a path of their own.


Agents do not align well with the managed path, which is designed to abstract away the underlying mechanisms. Agents require these mechanisms to be exposed as explicit, machine-readable contracts, such as declarative policies and typed interfaces that humans previously accepted as compliance requirements. Without these contracts, agents are forced to improvise across context and authority boundaries the platform never made explicit.

Agents also differ from primitives-path users. The primitives path assumes a senior engineer can bring judgment and accountability to the decision. An agent may reason over the inputs, but it cannot own the responsibility model the path quietly depends on. Allowing agents direct access to primitive infrastructure with minimal compliance leads to the same failures as before, only more rapidly. Standing credentials hand the agent excessive context, and there is no record of what the agent actually did with it.

This connects to my recent work. [Auth was built to limit context](/blog/auth-was-built-to-limit-context) looked at the mismatch between agents and the authorization model. [Ungoverned context supply chain risk](/blog/ungoverned-context-supply-chain-risk) explored how agents don't fit with provenance models. The same pattern shows up in platform user design: agents don't fit the operator model either.

## What agents need from the platform

Once agents become platform users, the old segmentation breaks.

An agent-native golden path is a path designed around the contracts an agent actually needs. The contracts that matter most have to be built into the path rather than bolted on later.

**Scoped context through a gateway.** Agents should not receive direct OAuth grants to services like Drive, Jira, GitHub, or identity providers. Instead, they receive access to a gateway that holds credentials and enforces workflow-specific policies. The gateway also manages classification and filtering, providing agents with a brokered view of the environment rather than full access.

**Task-bound credentials.** The OAuth grants AI tools hold today are almost always standing, while the task they support is ephemeral. That is backward; a task-bound credential is created when the agent picks up a ticket and expires when the ticket closes, with scope limited to what that ticket actually needs. The blast radius of a compromised agent shrinks to tasks open at that moment.

**Typed event streams.** Agents struggle to interpret unstructured logs because they must compress and summarize the information, which introduces errors. Event streams with defined schemas provide structured facts, such as deployment times and open incidents by component. The less an agent has to infer from messy logs, the fewer places it can invent the wrong story.

**A live state layer.** Most AI tools reference a static corpus, reading historical information rather than the system's current state. A live state layer addresses this by providing a queryable view of the system's present condition, including open incidents and active policy revisions. Agents can query this layer directly to determine if it is safe to merge or deploy.

**Evidence capture by construction.** Each grant issued by the gateway and every action performed by the agent should generate evidence as part of the workflow. The audit trail should be produced automatically during operations, not reconstructed after the fact.

The goal is not to add another compliance layer for agents. The same controls that limit agent access also ensure work is governable: scoped grants explain access, typed events document changes, the state layer records conditions at the time, and evidence capture creates a trustworthy record.

The primitives path for human experts remains, but its boundaries are now clearer. Previously, the distinction between standardized and fully custom primitives paths was a weak point. This distinction is easier to manage when the platform captures state, authority, and evidence as part of routine operations. Evidence records are now generated directly from the work, in a format accessible to compliance officers.

This doesn't mean the managed path disappears for teams that want everything handled for them, but it does change how things are organized. The managed path serves people who want to outsource the underlying work. The agent-native path serves tasks that agents execute on behalf of people, and the primitives path is reserved for the small number of teams working close enough to the system to handle the standard processes themselves. The segmentation has moved onto a different axis: who is actually doing the work.

## Where the next layer goes

Every layer in a mature platform has a reason for being there, and the stories above show that each one was earned. The real mistake is thinking the next set of layers belongs in the same place as the last. The teams a platform organization wants to keep will do more of their work through agents, and those agents need contracts the current managed path is not built to offer. The question worth spending time on this year is what the golden path should look like when most of the work on it is not typed at a keyboard.

AI investments face the same challenge. An AI strategy cannot bypass the platform organization, as any gaps in the platform will persist and hinder agents. Pilots may succeed, but broader rollouts stall for the same reasons platform adoption does. When the platform does not absorb the work, teams still carry it, even if the dashboard says adoption is high.

The Alberta company explicitly defined its segmentation and built a product to match. Platform organizations must do the same for agents. If the managed path remains the default for all new work, AI rollouts will inherit existing gaps. The next golden path must be designed for software executing tasks on behalf of people and teams, with context, authority, state, and evidence integrated from the beginning.

---

# AI Needs the Context Auth Was Built to Limit

_Published April 20, 2026 · https://brianwald.com/blog/auth-was-built-to-limit-context_

Vercel's recent security incident made me wonder how these types of attacks might evolve as AI tools become more widely used.

Vercel said the incident began with the compromise of [Context.ai](https://vercel.com/kb/bulletin/vercel-april-2026-security-incident), a third-party AI tool used by one of its employees. The attacker used that path to take over the employee's Google Workspace account and gain access to some Vercel environments and environment variables that were not marked sensitive. Vercel also warned that the compromised OAuth app could potentially affect hundreds of users across many organizations.

I think the underlying issue is that AI's need for context doesn't fit the model underneath. It reaches across the system boundaries auth was built to enforce. Modern auth models classify workloads into two rough patterns. One is bounded automation (e.g., CI, Terraform runs), where the workload's footprint could be described when the policy was written. The other is human-driven work, where the person is the integrator, filling gaps between tools. Both patterns let the auth model stay narrow because the context and the intended actions were both known before the policy was defined.

AI agents fit neither pattern because their usefulness depends on pulling in more context as they work (e.g., the repo, the issue, the runbook, the incident trail). At every step, more context _tends_ to make the tool more useful to the person running it. That is why zero-trust thinking becomes harder to apply cleanly here. The instinct behind the principle is still right, but useful AI tools have to pull context from across your environment as they run, and that is not a pattern the existing model knows how to describe.

Incidents like this are a preview of what happens when systems that depend on broad context keep getting layered onto an auth model whose purpose was least-privilege software access.

## Auth was built when context was knowable upfront

In the bounded automation case, zero trust and the modern authorization stack (OIDC, short-lived tokens, scoped service accounts, policy-as-code) matured alongside Terraform runs, CI/CD jobs, and service-to-service calls in microservices. These workloads share the trait that you can describe exactly what they need to do before they run. A Terraform plan needs provider credentials scoped to specific resources. A CI job needs certain registry pushes. The identity, action, and target are all known when the policy is written. This predictability makes fine-grained authorization functional. That is why approaches like SPIFFE, OIDC-based workload federation, and mesh-level authorization policies fit those environments so well. The workload is bounded at policy time, so authorization can be specific.

The other pattern is the human case, usually mediated through an authenticated user (SSO, OAuth, SAML). A person reads the issue, recalls the architectural decision from last quarter, pulls up the runbook in another tab, checks the incident channel, and mentally stitches it all together. The tools do not need broad reach because the person handles that part. Each system access is a separate OAuth handshake against a known human identity, with access scoped to what that system's policy allows. The auth model did not need to connect the systems because the human was the connection and checked independently at every hop. That is why least privilege felt correct and practical for so long. Access could be limited because the tools were not asked to do the synthesis.

AI agents break both patterns because they do the integration work humans used to do, but without per-system human checks. What they do is decided at runtime by the model, based on the task in front of it. You can write a policy for an agent, but any useful setting leads to two failure modes. If broad enough to let the agent do its job, the policy describes most of the environment. If narrow enough to constrain the action space, the agent hits boundaries on the work it should complete. The agent wants a large context window because it does not know in advance which parts of your environment will be relevant.

A code review agent that only sees the diff is not doing the work a human reviewer does. The reviewer also recalls prior incidents, design decisions behind the module, and the current state of dependencies, and is separately authorized to access each. If the agent is to do that work, it must reach the same sources. The per-hop human authorization that gated each step collapses into a single broad grant, and the bounded policy that described a workload's footprint has nothing to attach to.


That is why reading the Vercel incident simply as a case of a tool being given too much access misses the lesson. The tool needed that access to be useful, and the authorization model had no clean way to express "you can have broad reach, but only when the task warrants it, and only to the context the task requires." That kind of policy assumes either a human in the loop at each hop or a workload bounded at policy time, and agents are neither. The grant was wide because anything narrower would have made the tool ineffective.

## Why scope keeps expanding

Once both patterns stop holding, every AI tool rollout follows the same shape.

The first version of a code review agent ships with narrow access because that is what the review process was comfortable with, and it is underwhelming. Adding issue tracker integration lets the agent see what the change is supposed to do, and it improves. Wiring in prior MRs and incident history in the same service improves it again. Pulling in deploy telemetry and recent architecture decisions helps the tool produce reviews like a senior engineer. Each request is approved by someone who can see why broader access makes the tool more useful. None of the requests, alone, looks like a bad decision.

Broader access is what turns the tool from a demo into something teams actually use. You cannot "review your way out" of this with more discipline, because the pressure to expand scope comes from the tool doing its job better, not from anyone cutting corners. In a large enterprise, this happens in parallel across many teams, so no single reviewer sees the aggregate.

With AI tools, the blast radius is no longer in any single grant. It is in the accumulation of grants the tool picks up as it gets more useful. Even when each grant is scoped and short-lived, a tool that holds Drive, Jira, GitLab, and the identity provider together is a concentration of context that did not exist before. One compromise gives an attacker a synthesized view of the environment that most human users would never hold at once.

That invisibility erodes the discipline around these tools in small, ordinary ways. A grant goes in without a clean policy definition. A token's lifetime drifts upward because rotation breaks the tool. A review step is waived because the next scope request is labeled minor. A temporary test grant remains after the workflow ships.

What the auth stack was not built to surface is this aggregate.

## What the next access model probably needs

If useful AI keeps pushing toward broader access, "review harder" won't be enough. We probably need a different model for granting access in the first place.

A few directions seem more promising than the standing broad-scope approach most companies are drifting toward today.

**Mediated access.** Instead of every AI tool connecting directly to every source system, context should be brokered through a control layer that sits between the model and the systems it reads from. I described something like this in a [previous post](/blog/ungoverned-context-supply-chain-risk) as a context gateway, a place to classify, rank, and filter sources before anything reached the agent. The authorization argument points at the same layer. If you are already going to need a gateway to answer "what did the agent actually consume," it is also the natural place to enforce "what is the agent allowed to reach, for which task." At that point, provenance and authorization collapse into the same control plane. In practice, this means no AI tool gets a direct OAuth grant to Drive, Jira, GitHub, or the identity provider. It gets a grant to the gateway, and the gateway holds the real credentials, scoped with policy applied per workflow.

**Short-lived access.** Short-lived credentials are standard practice for bounded automation. STS-style token exchange, workload identity federation, CI runner tokens, scoped service accounts: the pattern is well understood. The gap is that AI tools rarely apply it to what matters most. The workflow runtime may be ephemeral, spun up per task and torn down afterward, but the OAuth grant the tool uses to reach Drive, Jira, GitHub, or the identity provider is typically standing and long-lived. That is backwards for this workload. A better model issues the context-access grant when the task starts, scopes it to what the task needs, and expires it when the task ends. For agents acting on a ticket, the ticket is the obvious anchor. The grant lives for the duration of that work, then goes away. This fits how agents are used in practice (minutes or hours, not months) and shrinks the blast radius of a compromised tool to tasks open at that moment.

**Context-bound access.** This may be the bigger shift. Today, most auth models focus on systems and scopes: can this tool read Drive, can it write to GitLab? The risk from AI is increasingly about which combinations of context can be assembled for a task, not which systems a tool can reach. The exposure lives in the combination. A tool that pulls together Drive, Jira, Slack, and the customer database into a single inference is a different class of risk, even when every individual grant looks reasonable. This suggests a policy model where access is bound to a task, time window, purpose, and sensitivity class, and the gateway decides at runtime which combinations are permitted. The policy responds to the state of the world when the request is made.

None of that is a finished design, but it is closer to what the problem actually requires than treating AI tools as ordinary SaaS integrations with slightly wider scopes.

## Auth has to move upstream

Authorization used to live at the point of access. An agent calls an API, the API checks the token, and access is granted or denied based on whether the caller has rights to that resource. This works when the policy question is "Can this caller read this resource?" It stops working when the question is "should this agent be allowed to assemble these pieces of context together, for this task, right now?"

That question has to be answered before the agent ever calls any API, at the orchestration layer, above individual system boundaries. Individual system APIs have no way to see the shape of the assembly happening above them. Each one is judging a single hop against a single identity, with no visibility into the broader workflow the request is part of.

Traditional auth classification lived downstream, inside each system's policy against its own resources. AI tools push classification upstream, to the layer where context is being pulled together from multiple systems for a single inference. Many details remain open: who owns that classification inside the organization, what the policy language is built from (tasks, purposes, sensitivity classes, etc.), how it integrates with existing identity providers, how it gets versioned as systems and workflows change. Mediated access, task-bound grants, and context-bound policy all point to the same shift. I think as this rolls out at scale, the boundary worth watching sits above the individual systems where auth decisions currently live.

---

# AI Is Forcing the Platform Rebuild That Should Have Happened Years Ago

_Published April 1, 2026 · https://brianwald.com/blog/ai-forcing-the-platform-rebuild_

The case for platform engineering has been easy to make on paper for years. Shared CI automation, built-in security and observability, golden paths that keep teams from reinventing infrastructure every time they spin up a service. Any experienced technical leader understands the value, but few end up funding it.

The reason is usually that building a platform is a massive undertaking with significant organizational change risks. In a 5,000-person engineering organization with 100 different tech stacks, consolidating onto a shared platform is a multi-year program that touches every team. The politics alone are enough to kill it. Executives would look at the upfront cost, compare it to the abstract promise of long-term efficiency, and choose to live with the mess. The ones who did start down the path usually watched it collapse under its own weight as every team argued for an exception.

When DevOps went mainstream, the cost of adoption was manageable because most organizations were still early in learning how to ship software at scale, which meant there was less to unwind. Platform engineering showed up later, after teams had already built years of process, tooling, and delivery habits around their existing model. By that point, even a strong case for rebuilding the foundation often was not enough to justify the disruption required to change how the organization actually worked.

AI is forcing enterprises to confront foundation work they had already decided to defer. I have seen this with customers that wanted to move quickly and treated platform concerns and the surrounding organizational change as something they could sort out later. A year or two in, the tools they rushed to adopt were already being replaced, and they were left renegotiating contracts, rebuilding integrations, and reworking the same problem from the beginning.

What stands out now is that some of the organizations in the strongest position are not the ones that moved first. Many early adopters signed contracts, deployed coding assistants, and assumed they were on a path that would hold, but the technology shifted faster than enterprise adoption cycles could keep up. As the market moved from assistants to agentic workflows and then toward broader orchestration across the software lifecycle, each step brought new integration work, new security requirements, and often another round of vendor and architecture decisions. The organizations that had no platform foundation to absorb those shifts kept having to rework the same problem, while the ones that built more deliberately were in a much better position once the landscape started moving under them.

## Platform engineering and AI adoption start compounding

The organizations making real progress are treating AI adoption and platform work as the same effort. As those start moving together, better foundations make AI easier to apply consistently, and growing AI adoption creates more pressure to standardize what sits underneath it.


Part of what is helping here is that AI-generated code tends to reinforce common patterns by leaning toward familiar frameworks, well-documented libraries, and conventional project structures. There is a fair criticism that this can narrow experimentation by pushing teams toward the same implementation choices, and I think that concern is real. I just think it matters a lot less when you are operating a large enterprise, where the bigger problem is usually too much variation across teams and too many local decisions that make the estate harder to support, secure, and govern. At that scale, consistency across the majority of applications is usually more valuable than preserving maximum flexibility at the framework layer. As the set of frameworks and structures begins to narrow, the platform team has a much smaller surface area to support, which makes golden paths, security controls, and compliance policy far easier to build once and apply broadly.

That is where adoption starts to scale. When the platform owns core concerns like CI pipelines, security scanning, access controls, and AI auditability, teams do not have to solve safe adoption on their own. The guardrails are built into the path they are already using.

Some organizations are already making this practical by moving organizational standards closer to the point where code gets generated, using things like rule files, MCP-connected tools and resources, and retrieval layers that feed approved internal context into the workflow. That matters because the platform team is no longer relying only on documentation or review to enforce decisions after the fact. The standards start showing up at the point where code is being created, and when the platform handles distribution those patterns can spread across the estate with much less friction. To me, that is one of the more important shifts happening right now, and it only works when there is enough platform underneath it to carry those standards consistently.

There is also a part of this I did not expect to matter as much as it does. AI can help with the platform work itself by analyzing a broad portfolio, identifying what should be standardized, surfacing consolidation opportunities across large numbers of repositories, and helping teams through parts of the migration onto shared foundations. I was more skeptical of that a year ago than I am now. I have seen enough of it work to think it is becoming a meaningful part of how enterprises will actually get through the rebuild.

None of this requires forcing every team onto an identical stack. The platform approaches that work best are composable, where teams inherit the shared value in CI, security, compliance, and deployment while still adjusting the parts that need to reflect the service they are building or the business domain they operate in. The platform only works when the shared parts stay shared and the places that need flexibility are exceptions.

## Fragmentation is breaking AI rollout

Most organizations are not approaching AI adoption as a platform problem. They are approaching it team by team, with local wrappers, scripts, and controls built around immediate needs. Each solution may make sense on its own, but across the organization they add up to another layer of fragmentation that has to be maintained every time the tooling changes.

What keeps showing up is that the context shaping AI output is still being handled locally instead of through the platform. The hard part is everything outside the repository that enterprise software depends on: which internal API should be used for authentication, what patterns have already been approved, how shared services behave in production, where dependencies already exist, and which decisions have already been made elsewhere in the organization. Developers carry that context because they have lived in the environment. AI does not have it unless the platform surfaces it. If you want agents operating effectively across the portfolio, you need a way to expose organizational context like service catalogs, API contracts, dependency maps, and architecture decision records in a way both humans and AI systems can actually use.

That gets harder fast when the surrounding infrastructure is fragmented. I have walked into organizations with a thousand Java projects where every one has a slightly different build configuration after years of local decisions and workarounds. When every project is a snowflake, even a simple change like rolling out a new security scan turns into a thousand separate CI templates. AI may increase the rate at which code gets produced, but if the delivery system around it is still fragmented, all it is doing is accelerating one part of a workflow that still breaks everywhere else.

Once you add compliance requirements, the cost of handling all of this locally becomes even harder to justify. If there is no standardized way to audit the inputs, inference, and outputs of AI-assisted systems, risk accumulates every time another tool or agent gets introduced. At enterprise scale, that has to be handled through the platform, not left to individual teams to solve with their own monitoring and controls.

I have been making the platform engineering case for years because these problems were already there. What has changed is that AI makes them harder to ignore. At this point, I do not think enterprises can scale AI well without shared foundations underneath it, unless they are willing to refactor the same decisions every year.

---

# Ungoverned Context Is a Real Supply Chain Risk for Agentic Workflows

_Published March 30, 2026 · https://brianwald.com/blog/ungoverned-context-supply-chain-risk_

Agentic workflows for software development are consuming more context from more sources than most teams realize, and almost none of it is governed. How an agent gathers and inherits context during a workflow is a significant and overlooked risk. Context poisoning can go undetected, particularly as larger context windows and better tooling make ingestion easier. But poisoning is just the adversarial version of a more general problem: context the agent cannot verify. Whether the source was tampered with or simply went stale, the agent proceeds on a version of reality that does not match the one it is operating in.

A trend I have long advocated is for platform engineering teams to own Agentic workflows the same way they own CI/CD pipelines today. These teams already build and maintain automation, integrate tools, standardize processes, and reduce complexity for developers. Extending this model to AI, platform teams can connect relevant data sources and create reusable workflows for development teams. These 'golden pathways' are governed, opinionated, and ready to use. That model makes sense. The gap is that most organizations still do not govern what an agent is allowed to treat as authoritative context. Each integrated data source expands the context supply chain, and with it the risk of prompt injection, stale guidance, and hidden upstream transformation.

This challenge is particularly difficult to address because:

* Most companies do not have clear ownership over what an agent is allowed to treat as authoritative.
* Prompt and response logging are still immature, but even where auditability exists, it often stops at the final payload. Earlier processing steps can still obscure risk. OWASP refers to this as [indirect prompt injection](https://owasp.org/www-community/attacks/Prompt_injection), but the practical attack surface is likely much broader than most teams assume.
* Context provenance is often incomplete, which makes it hard to determine where information actually came from once it has passed through several processing steps.
* Context is often assembled from multiple sources, but treated as one coherent input, which hides the lineage of each source.

## Why Context Cannot Be Trusted by Default

Consider a simple SDLC workflow: an agent is created to validate a merge request review against a ticket for a bug in an external system. The agent is configured to access the ticket's content.

The ticket or a linked artifact, such as a runbook, could contain poisoned content. This can enter the workflow in several ways, listed here in roughly increasing detection difficulty:


Even with prompt and context auditing, the system cannot validate information it is unaware of. A workflow may log the final context payload and still miss the hidden retrieval, ranking, enrichment, or summarization steps that shaped it. Validity checks may incorrectly assume the returned context is the sole source of truth, even when upstream context is ungoverned.

This lack of ownership is frequently overlooked and extends beyond technical vulnerabilities, such as prompt attacks and compromised documentation. A common example is open-source projects used as libraries. A traditional supply-chain attack involves code tampering, which can be mitigated through security processes such as pinning to a specific SHA or using curated services. But if documentation contains a prompt injection and an AI agent uses it for context, those mitigations do not apply. Even if you trust the documentation source, harder-to-detect variations exist, such as prompt injections embedded in stale or outdated documentation that an agent still retrieves as relevant.

This is a critical gap because most teams can identify the agent's runtime, but few can specify the authoritative sources the agent relied on.

## The False Sense of Confidence

In more mature software organizations, I have observed the implementation of audit gates to establish a clear record of what the agent consumed.

These organizations request the specific version of the internal API specification, the prompt, the model, and the tools used to gather context (such as agent.md files or MCP tools).

This looks thorough on the surface. However, when examining context gathering, they can usually specify only the retrieval method. They cannot provide the exact documentation used or identify the upstream processing steps that may have affected the payload.

Currently, Agentic workflow provenance is often treated like a traditional BOM, which collects metadata about the build process. However, agentic workflows are not linear and require a different approach.

* Why this dependency? Was it selected based on relevance determined by the context retrieval logic or specified in the prompt criteria?
* Where did this implementation pattern come from? Did it come from an approved source or from exploratory retrieval?
* What standard is this following? Was it based on the current standard or a stale internal document?
* Was this based on the current API contract or an outdated internal doc? Is there a way to track this level of detail?

## Not All Context Should Be Treated the Same

Most organizations have not explicitly distinguished between the types of context an agent can access, which makes it difficult to reduce risk.

You can have reasonably controlled and well-defined sources, such as API specifications, secure coding standards, deployment procedures, and data-handling rules, where ownership, versioning, and change control should be expected.

Then you have contextual operational sources, such as incident notes, postmortems, and temporary workarounds. These are probably fine, but they at least need to be time-bound and require attribution.

Last, you have the "human sources" that fill in the gaps, such as chat logs, ad hoc snippets, and personal notes. These may assist humans, but should not serve as authoritative inputs for production-impacting code.

The problem is that these agent retrieval systems blur all of this together. They surface what scores highest for relevance, not what has the strongest provenance.

As a result, a stale wiki page may outrank a reviewed API specification, and a workaround from an incident thread can inadvertently become policy. This is how non-malicious poisoned context can be accepted as truth.

Authoritative sources are condition-defining: they describe what is currently true about how the system should behave. The problem with classifying sources as trusted or untrusted is that classification is a snapshot. An API specification is authoritative until the contract changes. Whether the retrieved version still reflects how services actually communicate is a question about current state, not source provenance. An agent reading a superseded specification will make reasonable-looking decisions based on a version of the system that no longer exists, and a trust classification gives no signal that anything is wrong.

One idea that comes to mind is to have a way to flag sources as "trusted" or "untrusted" and to have a way to track the provenance of the context, then use a gateway to rank, filter, and produce a curated context payload based on that before the context is provided to the agent.

This gateway could also be used to enforce policies around context usage, such as requiring human review for certain types of context or limiting the amount of context that can be provided to an agent. The idea here is that the gateway would be the single source of truth for what context is provided to the agent and be able to run across multiple agent instances to ensure consistency and allow for centralized policy enforcement.


## The Wrong Fix Is Trying to Bless Everything

Some teams attempt to address this by creating a registry of approved knowledge sources with designated owners, versions, and mandatory traceability.

The intention is correct, but execution often falls short.

Attempting to govern every document, note, and operational detail creates a parallel documentation system that is difficult to maintain. Teams may stop updating it, guidance shifts back to tickets and chat threads, and the registry becomes outdated, creating a false sense of accuracy.

It is unnecessary to approve every piece of context. Instead, establish a contract specifying which sources may influence production-impacting changes in higher-risk workflows. Set flags for uncertainty to help human reviewers focus on critical tasks.

## Building a Context Bill of Materials (CxBOM)

For designated repositories, treat context as a supply chain input.

If an agent-assisted change affects payments, identity, customer data, pricing, access control, or other sensitive areas, the merge request should include sufficient information to reconstruct the context behind the change.

This process does not need to be complex; a minimal Context Bill of Materials is sufficient. Most of this information can be captured from the agent's execution logs and metadata. The key is tying the context back to the specific pipeline and the change set in the merge request.


* Which system did the context come from?
* Who owns it?
* What version was retrieved?
* What type of source was it: authoritative, operational, or ambient?
* Which pipeline run ties back to the change?
* What conditions were active at the time? Open incidents against relevant services, pending breaking changes in dependencies, or recent policy revisions that had not yet propagated to authoritative sources are part of the state the agent was operating in.

This is the minimum required to address questions during reviews, audits, and incidents. Without this, teams are forced to make assumptions after the fact. 

Furthermore, it gives reviewers enough lineage to decide whether the change should be trusted in the first place.

This is also where the source record and the condition record diverge. Source provenance tells you what the agent was given. The question an incident review or compliance examination will actually ask is why the agent behaved as it did given what it knew. An agent that approved a change because the relevant policy document looked current, while two open incidents involving the same service had been logged in the previous week, made a traceable error. Source provenance alone cannot surface that. A record of which conditions were active at the time of the decision is what turns a context log into a reconstruction.

> **Note:** This discussion focuses on context consumption specifically. Code produced by the agent should also be traceable to the model, tools, and prompt that generated it, but that is a separate topic. If you want to go deeper on that side of it, I'd suggest reading [This article about code provenance](https://atomicdotdev.substack.com/p/control-planes-over-forges) by Lee Faus.

## This Is Also Why Tool Evaluations Never Really End

When the context layer is unmanaged, tool evaluations become a matter of trust.

Evaluations must consider retrieval behavior, source handling, and provenance in addition to model quality. This often leads organizations to repeat evaluations without gaining confidence.

The trust boundary remains unstable because the context layer is still unmanaged.

A shared context contract stabilizes the trust boundary, allowing tool changes to become configuration decisions rather than requiring full re-validation.

## Where I Would Start

Before building anything, audit what your agents are actually consuming. For each agentic workflow, map every source that feeds context into the agent: retrieval endpoints, knowledge bases, linked artifacts, tool outputs, and any upstream enrichment or summarization steps. For each source, document who owns it, whether it is versioned, how frequently it changes, and whether the agent can distinguish a current version from a stale one. Most teams that do this for the first time find sources in the chain they did not know existed.

That audit gives you the inventory. The next step is classification. Apply the authoritative, operational, and ambient distinction from earlier in this article to each source and assign ownership. Authoritative sources get versioning and change-control requirements. Operational sources get time-bound validity. Ambient sources get flagged so reviewers know they are present but unverified. This classification becomes the contract that the workflow operates under.

With that contract in place, the next evolution is a context bus: a processing layer that sits between your sources and the agent, responsible for enforcing the contract at retrieval time. The bus handles source classification, provenance tagging, staleness detection, and policy enforcement before the context payload ever reaches the agent. It is also where you generate the CxBOM. Instead of relying on the agent's own execution logs to reconstruct what happened, the bus produces a structured record of what was retrieved, from where, at what version, and what policies were applied. This is the layer that makes context governance operational rather than aspirational, and it is where platform engineering teams should be investing once the audit and classification work is done.

---

# Notes from the Field

_Published March 25, 2026 · https://brianwald.com/blog/why-i-write_

I spend my days talking to engineering leaders at some of the world's largest organizations. The conversations are fast, the problems are real, and the patterns repeat in ways that most people never get to see.

This blog is where I process those patterns. What's working, what's failing, and what the gap between the two actually looks like up close.

The timing matters. AI is reshaping how software gets built, reviewed, shipped, and secured, and the noise-to-signal ratio in the industry has never been worse. Everyone has a take. Not enough people are sharing what's actually happening inside the organizations doing the work, everything is focused on hype. That's the gap I want to fill.

## What to expect

I write about technical leadership, AI software development at scale,and the messy reality of platform engineering. Some posts will be opinionated. Some will be data-driven. All of them will be grounded in what I'm actually seeing. The realities you don't see in the trending posts on Hacker News. Yes, maybe its a bit niche, but I have found many technology leaders are looking for some grounded, tested, and practical advice so I figured I'd share what I'm seeing.

If you lead engineering teams, build platforms, or make technology decisions for your organization, this may be worth a read.

If there are topics you are looking to learn more about, please reach out, I'd love to hear from you. [bw@brianwald.com](mailto:bw@brianwald.com)

---

# Musings

---

## AI writing is bad, so I built around it

_Published April 10, 2026 · https://brianwald.com/musings/ai-writing-process_

I have always wanted to write more, but I've never been able to get into the habit of going through the full cycle where I am happy with the output. I have stacks of notes and half-finished articles and thoughts sitting in my drafts folder. I think this is because I've always tried to write in a traditional way, like keeping a journal or writing essays. I've never really found a way to keep my attention on the boring parts of the process (restructuring, editing, etc).

When AI came around, I was infatuated with its ability to turn my ideas into full content and remove the parts I dreaded. I thought it was going to be the key to unlocking my creativity and helping me write more. The problem is, it didnt take long for me to realize that I hate the way AI actually does the writing. It generallly was able to produce content that was easier to read than my way of writing, but it just felt so hollow and meaningless. In fact, now adays I cant even stand reading any content that other have written that are clearly AI generated. I can't describe it exactly, but it just feels like I am reading an assembly of words that have been strung together in a way that makes sense, but lacks any meaning (which of course is exactly what LLMs technically do). I think about the book by Malcom Gladwell "Blink", where he talks about how we make quick decisions based on limited information, and how those decisions can be just as good as, if not better than, decisions made with more information. When I use AI for writing, I feel like it extrapolates my ideas in a way that is like "yeah, thats fine" but I read it again later and hate it.


I could get into the whole backstory and my journey to wrangle in my diagnosis of ADHD, and how it has impacted me, but you dont care and thats not what I am here to write about. The point is, I honestly _love_ the way I think, even if ADHD makes me bad at following through. But now with AI I have this great opportunity to use it in a way that removes the hard part of writing for me while allowing me actually tackle the problems that prevented me from getting my ideas and thoughts out to the world (whether anyone cares is a different story).

So I started think about what I am actually uniquely good at, and what part of AI do I think is actually valuable for writing and came up with a startegy. 

What I am good at: Coming up with unique ideas and perspectives.
Where I often fail: Formating and structuring my thoughts in a way that is easy to read and understand.

What AI is good at: Pattern and trend matching, researching, and structuring
Where AI fails: Coming up with unique insights, or having a genuine opinion on anything.

So I stopped prompting AI to write for me. Instead I built a CLI that runs a set of agents as background processes while I write. When I save the file, it kicks off and reacts, helping sort through my ideas in a structure I can go and write myself.

```
~/sites/writing/
├── voice.md              # style guide and voice instructions
├── agents/
│   ├── direction.md      # thread tracking
│   ├── research.md       # claim flagging
│   ├── structure.md      # evaluated and creates structural patterns
│   └── signals.md        # live web search on the topics I am discussing
└── workspaces/
    └── <article>/
        ├── bin.md        # raw thought dump — write here, no structure required
        ├── backlog.md    # off-topic ideas worth keeping, extracted by agents
        ├── peer.md       # agent feedback, auto-updated on every save
        ├── shape.md      # structured outline
```

```sh
write work    # start agents watching bin.md
write assess  # bin + peer notes used to create the shape.md
```

`write work` starts the watch loop. I open `bin.md` and dump all my thoughts, tangents, or whatever else comes to mind. Every save triggers a diff-based agent cycle: 
* `direction.md` tracks what I am actually arguing so I don't lose the thread
* `research.md` flags claims that need evidence and pulls counterpoints I should address
* `structure.md` looks at the structural shape of what I have and suggests an outline
* `signals.md` searches the web for related work like HackerNews, Pragmatic Engineer, etc. so I know if I am actually saying something new/interesting

_BTW, I added a cheap Haiku triage step that gates each cycle so I am not burning Opus calls when nothing substantive changed._

I inevitably go off on tangents in `bin.md`, and I don't want to lose a genuinely good idea just because it's off-topic. An agent extracts those into `sparks.md` with enough context that I can pick one up later as its own article.

`write assess` takes the raw dump, agent feedback, and research and produces `shape.md`. In here I have it organize my arguments, call out gaps, etc.

Even though the agents never write my drafts, they still need to understand how I write so their feedback feels like me. `voice.md` was built from my previous work and a list of things I want to ban the AI from doing that I dont like.

The output is a structured outline that I can start to build the content for. Its not perfect but it has certainly helped me get over the hump.