8 MIN READ
Ana Jiménez Santamaría | 15 July 2026
Open Source Program Offices (OSPOs) have spent years helping organizations make sense of the open source they depend on: licenses, dependencies, security, standards, and the ecosystem engagements and partnerships behind the software they use strategically.
Lately, though, it seems the landscape has started to shift. As AI becomes more embedded in digital infrastructure and moves into production, organizations are beginning to bring a familiar set of questions to their OSPOs, but this time in relation to AI systems. The United Nations itself has framed OSPOs as an organizational mechanism for turning open source in AI infrastructure from an aspiration into operational capability.
Agentic AI is one area where this shift is becoming visible. As the governance landscape matures (NIST AI Risk Management Framework, ISO/IEC 42001, EU AI Act main enforcement opening on 2 August 2026) and teams begin experimenting with AI agents, familiar questions start landing at the OSPO, but applied to a new technical layer:
- Which protocols should we standardize on?
- What policies should guide AI-assisted contributions to our repositories?
- How do we know what an agent actually did? Can we audit it later?
- Where should human oversight and approval sit in the agent loop?
This article introduces the parts of the agentic AI ecosystem where OSPO practitioners may find useful to understand as they apply their existing skills to this new layer.
Before unpacking those pieces, let’s begin with the foundational question that connects the rest of this story: what organizational value can an OSPO create?
Measuring OSPO value
A recent Linux Foundation report by Ibrahim Haddad, Measuring OSPO Value, gives OSPOs a way to start. The report measures OSPO value across four interrelated dimensions: ROI and cost avoidance; resilience; risk foresight; and strategic influence.
The questions teams are starting to bring to OSPOs about AI agents are questions about value across those same four dimensions:
- preventing lock-in creates resilience;
- avoiding an unnecessary migration supports cost avoidance;
- catching a misleading agent output before it reaches production is risk foresight;
- participating early in emerging standards creates strategic influence
As internal teams begin building with AI agents and move into production, new questions will naturally reach the teams responsible for open source strategy and involved in AI governance. The good news is that many of the answers build on familiar OSPO capabilities, applied to a new layer of technology.
In Poisoning the Well: Why AI Governance Is the OSPO's New Frontier, Madhusudanan GK (NatWest Group OSPO) argues that with AI, the failure surface moves from deterministic logic into behavior baked into data, models, and retrieval pipelines that traditional software supply-chain tooling was not built to describe.
Agent and deterministic guardrails
The realization that helped me make sense of agentic AI was that an “AI agent” is really a few components fused. Once you separate them, everything else in the stack starts to make sense as pieces that complement one or the other.
There is a framing based on The Anatomy of an Agent Harness, where the harness is defined as "every piece of code, configuration, and execution logic that isn't the model itself", including tools, orchestration logic, and middleware for deterministic execution. Let’s explore more this idea.
Agent = model + harness and what that means for an OSPO
- The model is the part that *reasons*. It reads a request and decides what to do. On its own, though, a model can't actually do anything: it just produces text. It can say "I should look up the repo's stats," but it can't reach out and get them.
- The harness is the part that turns reasoning into action. It takes the model's output, notices it wants to call a tool, runs that tool, feeds the result back to the model, and keeps the whole loop going. It also manages the conversation's context and holds the credentials for the model provider
Project Goose is one example of an open source harness that provides the runtime and orchestration layer around several models and providers.
Guardrails at the harness layer
The model is where probabilistic reasoning happens. Its outputs are not fully predictable, and its internal reasoning cannot be audited line by line in the same way as conventional software. The harness, however, is where deterministic guardrails can be introduced.
You cannot make a probabilistic model fully predictable, but you can surround it with enforceable guardrails. This is where the OSPO’s experience with provenance, policy, and ecosystem engagements can transfer directly to the agentic AI stack.
There's a recent case study from Hoseong Lee, an engineer in the aerospace sector, that laid out why goose is currently the most practical option for air-gapped industrial environments, worth reading if you're thinking about AI policy at OSPO scale.
The other reason the split matters is that the two parts are separable. You can keep your harness and change your model, or the other way around. You have control and customization to decide what part to keep open, closed, in the cloud, or local things that an OSPO has usually helped teams advise to deal with lock-in.
An AWS Builder Center essay, Agent harness: where engineers add value when models keep getting smarter, makes the case: as models converge on capability, the harness is where teams differentiate. That reframes "which model?" as a much less interesting question than "which harness, and does it fit us?"
How the pieces fit together
Once the model and harness are separated, a set of open pieces comes into view.
To make this article simpler, most of the pieces I'll walk through below are AAIF-hosted projects. The broader agentic ecosystem includes many other components, so this is not an exhaustive tour, just one introductory slice.
MCP (Model Context Protocol): Connects the harness to tools, resources, and reusable prompts through an open client-server protocol
OSPO example: Standardize tool integrations through an open protocol and reduce vendor lock-in
MCP servers: Host and execute capabilities such as retrieving GitHub metrics, querying databases, or accessing internal services
OSPO example: Work with security and platform teams to standardize the organization-approved capabilities available to AI agents
AGENTS.md: Provides repository-specific instructions and guidance for AI agents
OSPO example: Standardize contribution policies, repository guidance, and AI-assisted development instructions across projects
Agentgateway: Provides shared routing, authentication, observability, and policy controls across agents, models, and MCP servers
OSPO example: Work with security and platform teams to translate open source and AI governance policies into audit requirements
A2A (Agent-to-Agent): Enables agents to communicate and coordinate with other agents
OSPO example: Preserve interoperability between multi-agent systems
Notice that these open pieces sit at three different layers:
- Within the harness: as implementations (MCP client, A2A support, tool orchestration, execution logic)
- Harness boundary / Protocol contracts: as open protocols that any compatible harness can implement and use to communicate (MCP, A2A)
- Alongside the harness / Shared infra: sits between agent runtimes and external systems, providing capabilities such as traffic routing, policy enforcement, observability, etc (agentgateway)
This separation helps keep the stack modular, interoperable, and replaceable. The harness implements the protocol contracts; the contracts stay stable across harness changes, while shared infrastructure can enforce security, governance, and operational policies consistently across many agents.
OSPO teams do not need to master any of these technologies individually.
Closing thoughts
Openness moves layer by layer: The old question “is this open source or not?" gets more granular into “is the harness open?” “Is the protocol open?” “Is the model swappable, or are we cornered into one vendor?” An open harness plus an open protocol keeps the model a choice for the organization.
Standards advocacy is the familiar move, one layer up: An open harness, an open tool protocol, open repository guidance, and interoperable infrastructure can help preserve choice as agentic systems mature. That instinct transfers directly from decades of OSPO work; only the surface has moved.
Ecosystem engagement remains a key part of the job: Whether a team is evaluating an AAIF project or another tool, the questions around project and community health still apply (who governs the project, is development concentrated in one company, is the roadmap open, are contributors diverse, is the project actively maintained, can the organization influence its direction, is the standard likely to remain interoperable?).
Cross-collaboration needs to happen: Security, legal, privacy, data, risk, platform engineering, architecture, and product teams all have responsibilities. At the same time, OSPOs can work with these teams and bring a powerful combination of skills (open source governance, ecosystem awareness, standards engagement). That combination is what makes them the natural home for a lot of what agentic AI is beginning to ask of open source strategy.
If you are beginning this journey and want to build shared knowledge and practical best practices with peers, the TODO Group Agentic AI to Empower OSPOs Working Group is exploring these themes in practice. The group meets biweekly to learn together on both the practical use of agents in day-to-day OSPO work and how they can help their organizations engage with the open standards, projects, and ecosystems emerging around agentic AI.
Ana Jiménez Santamaría is a Sr. Project Manager for the Linux Foundation and an AAIF Ambassador. https://www.linkedin.com/in/