America’s AI Action Plan outlines a comprehensive strategy for the country’s leadership in AI. The plan seeks, in part, to accelerate AI adoption in the federal government. However, there is a gap in that vision: agencies have been slow to adopt AI tools to better serve the public. The biggest barrier to adopting and scaling trustworthy AI isn’t policy or compute power — it’s the foundation beneath the surface. How agencies store, access and govern their records will determine whether AI succeeds or stalls. Those records aren’t just for retention purposes; they are the fuel AI models need to power operational efficiencies through streamlined workflows and uncover mission insights that enable timely, accurate decisions. Without robust digitalization and data governance, federal records cannot serve as the reliable fuel AI models need to drive innovation.
Before AI adoption can take hold, agencies must do something far less glamorous but absolutely essential: modernize their records. Many still need to automate records management, beginning with opening archival boxes, assessing what is inside, and deciding what is worth keeping. This essential process transforms inaccessible, unstructured records into structured, connected datasets that AI models can actually use. Without it, agencies are not just delaying AI adoption, they’re building on a poor foundation that will collapse under the weight of daily mission demands.
If you do not know the contents of the box, how confident can you be that the records aren’t crucial to automating a process with AI? In AI terms, if you enlist the help of a model like OpenAI, the results will only be as good as the digitized data behind it. The greater the knowledge base, the faster AI can be adopted and scaled to positively impact public service. Here is where agencies can start preparing their records — their knowledge base — to lay a defensible foundation for AI adoption.
Step 1: Inventory and prioritize what you already have
Many agencies are sitting on decades’ worth of records, housed in a mix of storage boxes, shared drives, aging databases, and under-governed digital repositories. These records often lack consistent metadata, classification tags or digital traceability, making them difficult to find, harder to govern, and nearly impossible to automate.
This fragmentation is not new. According to NARA’s 2023 FEREM report, only 61% of agencies were rated as low-risk in their management of electronic records — indicating that many still face gaps in easily accessible records, digitalization and data governance. This leaves thousands of unstructured repositories vulnerable to security risks and unable to be fed into an AI model. A comprehensive inventory allows agencies to see what they have, determine what is mission-critical, and prioritize records cleanup. Not everything needs to be digitalized. But everything needs to be accounted for. This early triage is what ensures digitalization, automation and analytics are focused on the right things, maximizing return while minimizing risk.
Without this step, agencies risk building powerful AI models on unreliable data, a setup that undermines outcomes and invites compliance pitfalls.
Step 2: Make digitalization the bedrock of modernization
One of the biggest misconceptions around modernization is that digitalization is a tactical compliance task with limited strategic value. In reality, digitalization is what turns idle content into usable data. It’s the on-ramp to AI driven automation across the agency, including one-click records management and data-driven policymaking.
By focusing on high-impact records — those that intersect with mission-critical workflows, the Freedom of Information Act, cybersecurity enforcement or policy enforcement — agencies can start to build a foundation that’s not just compliant, but future-ready. These records form the connective tissue between systems, workforce, data and decisions.
The Government Accountability Office estimates that up to 80% of federal IT budgets are still spent maintaining legacy systems. Resources that, if reallocated, could help fund strategic digitalization and unlock real efficiency gains. The opportunity cost of delay is increasing exponentially everyday.
Step 3: Align records governance with AI strategy
Modern AI adoption isn’t just about models and computation; it’s about trust, traceability, and compliance. That’s why strong information governance is essential.
Agencies moving fastest on AI are pairing records management modernization with evolving governance frameworks, synchronizing classification structures, retention schedules and access controls with broader digital strategies. The Office of Management and Budget’s 2025 AI Risk Management guidance is clear: explainability, reliability and auditability must be built in from the start.
When AI deployment evolves in step with a diligent records management program centered on data governance, agencies are better positioned to accelerate innovation, build public trust, and avoid costly rework. For example, labeling records with standardized metadata from the outset enables rapid, digital retrieval during audits or investigations, a need that’s only increasing as AI use expands. This alignment is critical as agencies adopt FedRAMP Moderate-certified platforms to run sensitive workloads and meet compliance requirements. These platforms raise the baseline for performance and security, but they only matter if the data moving through them is usable, well-governed and reliable.
Infrastructure integrity: The hidden foundation of AI
Strengthening the digital backbone is only half of the modernization equation. Agencies must also ensure the physical infrastructure supporting their systems can withstand growing operational, environmental, and cybersecurity demands.
Colocation data centers play a critical role in this continuity — offering secure, federally compliant environments that safeguard sensitive data and maintain uptime for mission-critical systems. These facilities provide the stability, scalability and redundancy needed to sustain AI-driven workloads, bridging the gap between digital transformation and operational resilience.
By pairing strong information governance with resilient colocation infrastructure, agencies can create a true foundation for AI, one that ensures innovation isn’t just possible, but sustainable in even the most complex mission environments.
Melissa Carson is general manager for Iron Mountain Government Solutions.
Digital information travels through fiber optic cables through the network and data servers behind glass panels in the server room of the data center. High speed digital lines 3d illustration
On Nov. 3, Jeff Koses, the General Services Administration’s senior procurement executive, posted an article on LinkedIn announcing that the “RFO is in play.” The article highlighted that GSA, the U.S. Department of Agriculture, and the Department of Homeland Security had issued all the deviations with Nov. 3 as the effective date for the changes. A new era begins for the Federal Acquisition Regulation as agencies and departments continue to work towards implementing the RFO deviations and updating their supplemental acquisition regulations. The procurement policy teams responsible for drafting the deviations, the Practitioner’s Albums, and the FAR Companion deserve praise for the thoughtful, integrated, and comprehensive effort. The streamlined RFO is an improvement on the FAR, providing a clear, concise, and coherent acquisition framework for government and industry.
As we know, the next phase of the process, the public rulemaking, is critical to the long-term success of the RFO. The rule making process provides the public, including key stakeholders across the procurement community, with the formal opportunity, consistent with law, to comment on the deviations in the form of proposed or interim rules. A robust, transparent process will ensure that the deviations become final rules, cementing the RFO. The Coalition for Common Sense in Government Procurement’s members look forward to the start of the public rule making phase and the opportunity to formally comment on the revised FAR.
The RFO is central to improving the efficiency and effectiveness of the procurement system. The FAR establishes the ground rules for government and industry transacting business in support of agency missions. The RFO streamlines and clarifies the ground rules thereby increasing competition and access to the commercial market.
Leveraging the RFO to deliver best value mission support for customer agencies and the American people centers on three critical elements: (1) requirements development (2) the acquisition workforce; and (3) operational commercial best practices.
1. Developing Sound Requirements
Clear, concise, and well communicated requirements are foundational to successful procurement outcomes that deliver best value mission support. Program offices must play a central role in developing requirements. In this regard, coordination between senior program managers and contracting officers drives effective requirements development for complex requirements. Part and parcel of requirements development is market research. Understanding the capabilities and technologies in the commercial market will inform sound requirements. Too often, government requirements reflect a “Hail Mary” approach that seeks a capability well beyond what is currently commercially available rather acquiring the 80 percent commercial solution that can meet mission needs. As with most “Hail Marys” these requirements often end unfulfilled and undelivered.
Finally, today’s outcome-based contracts are yesterday’s performance-based contracts. The administration rightly has identified outcome-based requirements as a strategy that can increase competition, improve performance and achieve greater savings. The long-standing challenge of outcome-based contracting is the articulation and implementation of clear outcomes and associated measures to support contractor performance and government contract administration. It all starts with the statement of objectives. Management focus on and investment in outcome-based requirements development is a commercial best practice. The government should look to emulate this commercial best practice to unlock the positive potential of outcome-based contracting. Perhaps leveraging technology (e.g. artificial intelligence) for data analysis and analytics can support the government’s requirements development process.
2. Embracing The Acquisition Workforce
The RFO vests greater discretion to the contracting officer. Some of the commentary around the RFO has raised the potential of increased inconsistency in contracting operations due to greater discretion. The Practitioner’s Albums, FAR Companion, and Category Management Buying Guides are the starting point for the acquisition workforce. As the implementation of the RFO moves forward, translating real life experience with the revised ground rules into a set of operational best practices will be important in fostering consistency. Further, consistent, strategic investments in acquisition training and professional development will enhance sound decision making. Finally, management support and corresponding lines of authority in contracting operations will foster consistency and accountability in the process.
3. Adopting Commercial Best Practices in Procurement Operations
The hallmark of the RFO is its leveraging of the commercial market. The RFO reduces the number of clauses applicable to commercial contracts, strengthens the preference for commercial products and services, and streamlines the overall procurement process. As a policy statement, the RFO recognizes that access to, and competition from the commercial market drives innovation, efficiency, and increases value for the government mission.
Adopting commercial best practices in procurement operations is the third key element in leveraging the RFO to deliver best value mission support for the American people. For example, as mentioned above, it is a commercial best practice to invest significant time and resources in requirements development. Sound outcome-based requirements are the blueprint for success. Vigorous competition for sound requirements is the single most effective way to drive value for the taxpayer. Avoiding government-unique, noncommercial practices is the other side of the coin. Operational practices that overregulate or reregulate the procurement process will limit competition, reduce access to the commercial market, and undermine mission support. It will be incumbent at the operational level to embrace commercial best practices while avoiding/eliminating noncommercial practices that undermine the efficiency and effectiveness of the procurement process.
The Justice Department recently resolved several investigations into federal contractors’ cybersecurity requirements as part of the federal government’s Civil Cyber-Fraud Initiative. The initiative, first announced in 2021, ushered in the DOJ’s efforts to pursue cybersecurity-related fraud by government contractors and grant recipients pursuant to the False Claims Act. Since then, the DOJ has publicly announced approximately 15 settlements against federal contractors, with the DOJ undoubtedly conducting even more investigations outside of the public’s view.
As an initial matter, these latest settlements signal that the new administration has every intention of continuing to prioritize government contractors’ cybersecurity practices and combating new and emerging cyber threats to the security of sensitive government information and critical systems. These settlements also coincide with the lead up to the Nov. 10 effective date of the Defense Department’s final rule amending the Defense Federal Acquisition Regulation Supplement, which incorporates the standards of the Cybersecurity Maturity Model Certification.
Key DOJ cyber-fraud decisions
The first of these four recent DOJ settlements was announced in July 2025, and resulted in Hill Associates agreeing to pay the United States a minimum of $14.75 million. In this case, Hill Associates provided certain IT services to the General Services Administration. According to the DOJ’s allegations, Hill Associates had not passed the technical evaluations required by GSA for a contractor to offer certain highly adaptive cybersecurity services to government customers. Nevertheless, the contractor submitted claims charging the government for such cybersecurity services, which the DOJ alleged violated the FCA.
The second settlement, United States ex. rel. Lenore v. Illumina Inc., was announced later in July 2025, and resulted in Illumina agreeing to pay $9.8 million — albeit with Illumina denying the DOJ’s allegations. According to the DOJ, Illumina violated the FCA by selling federal agencies, including the departments of Health and Human Services, Homeland Security and Agriculture, certain genomic sequencing systems that contained cybersecurity vulnerabilities. Specifically, the DOJ alleged that with respect to the cybersecurity of its product, Illumina: (1) falsely represented that its software and systems adhered to cybersecurity standards, including standards of the International Organization for Standardization and National Institute of Standards and Technology; (2) knowingly failed to incorporate product cybersecurity in its software design, development, installation and on-market monitoring; (3) failed to properly support and resource personnel, systems and processes tasked with product security; and (4) failed to adequately correct design features that introduced cybersecurity vulnerabilities.
That same day, the DOJ announced its third settlement, which was with Aero Turbine Inc., and Gallant Capital Partners, LLC (collectively, “Aero”), and resulted in a $1.75 million settlement. This settlement resolved the DOJ’s allegations that Aero violated the FCA by knowingly failing to comply with the cybersecurity requirements of its contract with the Department of the Air Force. Pursuant to the contract, Aero was required to implement the security requirements outlined by NIST Special Publication 800-171, “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations,” but failed to fully do so. This included failing to control the flow of and limit unauthorized access to sensitive defense information when it provided an unauthorized Egypt-based software company and its personnel with files containing sensitive Defense information.
The fourth and latest DOJ settlement was announced in Sept. 2025, and resolved the DOJ’s FCA lawsuit against the Georgia Tech Research Corporation. As part of the settlement, GRTC agreed to pay $875,000 to resolve allegations resulting from a whistleblower complaint that it failed to meet the cybersecurity requirements in its DoD contracts. Specifically, the DOJ alleged that until December 2021, the contractor failed to install, update or run anti-virus or anti-malware tools on desktops, laptops, servers and networks while conducting sensitive cyber-defense research for the DoD. The DOJ further alleged that the contractor did not have a system security plan setting out cybersecurity controls, as required by the government contract. Lastly, the DOJ alleged that the contractor submitted a false summary level cybersecurity assessment score of 98 to the DoD, with the score being premised on a “fictitious” environment, and did not apply to any system being used to process, store or transmit sensitive Defense information.
Takeaways for federal contractors
These recent enforcement actions provide valuable guidance for federal contractors.
DOJ has explicitly stated that cyber fraud can exist regardless of whether a federal contractor experienced a cyber breach.
DOJ is focused on several practices to support allegations of cyber fraud, including a federal contractor’s cybersecurity practices during product development and deployment, as well as contractors’ statements regarding assessment scores and underlying representations.
DOJ takes whistleblower complaints seriously, with several of these actions stemming from complaints by federal contractors’ former employees.
To mitigate these risks, federal contractors should ensure that they understand and operationalize their contractual obligations, particularly with respect to the new DFARS obligations.
Federal contractors would be well advised to:
(1) review and understand their cybersecurity contractional obligations;
(2) develop processes to work with the appropriate internal teams (information security, information technology, etc.) to ensure that contractual obligations have been appropriately implemented; and
(3) develop processes to monitor compliance with the contractual obligations on an ongoing basis.
Joshua Mullen, Luke Cass, Christopher Lockwood and Tyler Bridegan are partners at Womble Bond Dickinson (US) LLP.
In 2025 AI reshaped how teams think, build, and deliver software. We’re now at a point where “AI coding assistants have quickly moved from novelty to necessity [with] up to 90% of software engineers us[ing] some kind of AI for coding,” Addy Osmani writes. That’s a very different world to the one we were in 12 months ago. As we look ahead to 2026, here are three key trends we have seen driving change and how we think developers and architects can prepare for what’s ahead.
Evolving Coding Workflows
New AI tools changed coding workflows in 2025, enabling developers to write and work with code faster than ever before. This doesn’t mean AI is replacing developers. It’s opening up new frontiers to be explored and skills to be mastered, something we explored at our first AI Codecon in May.
AI tools in the IDE and on the command line have revived the debate about the IDE’s future, echoing past arguments (e.g., VS Code versus Vim). It’s more useful to focus on the tools’ purpose. As Kent Beck and Tim O’Reilly discussed in November, developers are ultimately responsible for the code their chosen AI tool produces. We know that LLMs “actively reward existing top tier software engineering practices” and “amplify existing expertise,” as Simon Willison has pointed out. And a good coder will “factor in” questions that AI doesn’t. Does it really matter which tool is used?
The critical transferable skill for working with any of these tools is understanding how to communicate effectively with the underlying model. AI tools generate better code if they’re given all the relevant background on a project. Managing what the AI knows about your project (context engineering) and communicating it (prompt engineering) are going to be key to doing good work.
The core skills for working effectively with code won’t change in the face of AI. Understanding code review, design patterns, debugging, testing, and documentation and applying those to the work you do with AI tools will be the differential.
The Rise of Agentic AI
With the rise of agents and Model Context Protocol (MCP) in the second half of 2025, developers gained the ability to use AI not just as a pair programmer but as an entire team of developers. The speakers at our Coding for the Agentic World live AI Codecon event in September 2025 explored new tools, workflows, and hacks that are shaping this emerging discipline of agentic AI.
Software engineers aren’t just working with single coding agents. They’re building and deploying their own custom agents, often within complex setups involving multi-agent scenarios, teams of coding agents, and agent swarms. This shift from conducting AI to orchestrating AI elevates the importance of truly understanding how good software is built and maintained.
We know that AI generates better code with context, and this is also true of agents. As with coding workflows, this means understanding context engineering is essential. However, the differential for senior engineers in 2026 will be how well they apply intermediate skills such as product thinking, advanced testing, system design, and architecture to their work with agentic systems.
AI and Software Architecture
We began 2025 with our January Superstream, Software Architecture in the Age of AI, where speaker Rebecca Parsons explored the architectural implications of AI, dryly noting that “given the pace of change, this could be out of date by Friday.” By the time of our Superstream in August, things had solidified a little more and our speakers were able to share AI-based patterns and antipatterns and explain how they intersect with software architecture. Our December 9 event will look at enterprise architecture and how architects can navigate the impact of AI on systems, processes, and governance. (Registration is still open—save your seat.) As these events show, AI has progressed from being something architects might have to consider to something that is now essential to their work.
We’re seeing successful AI-enhanced architectures using event-driven models, enabling AI agents to act on incoming triggers rather than fixed prompts. This means it’s more important than ever to understand event-driven architecture concepts and trade-offs. In 2026, topics that align with evolving architectures (evolutionary architectures, fitness functions) will also become more important as architects look to find ways to modernize existing systems for AI without derailing them. AI-native architectures will also bring new considerations and patterns for system design next year, as will the trend toward agentic AI.
As was the case for their engineer coworkers, architects still have to know the basics: when to add an agent or a microservice, how to consider cost, how to define boundaries, and how to act on the knowledge they already have. As Thomas Betts, Sarah Wells, Eran Stiller, and Daniel Bryant note on InfoQ, they also “nee[d] to understand how an AI element relates to other parts of their system: What are the inputs and outputs? How can they measure performance, scalability, cost, and other cross-functional requirements?”
Companies will continue to decentralize responsibilities across different functions this year, and AI brings new sets of trade-offs to be considered. It’s true that regulated industries remain understandably wary of granting access to their systems. They’re rolling out AI more carefully with greater guardrails and governance, but they are still rolling it out. So there’s never been a better time to understand the foundations of software architecture. It will prepare you for the complexity on the horizon.
Strong Foundations Matter
AI has changed the way software is built, but it hasn’t changed what makes good software. As we enter 2026, the most important developer and architecture skills won’t be defined by the tool you know. They’ll be defined by how effectively you apply judgment, communicate intent, and handle complexity when working with (and sometimes against) intelligent assistants and agents. AI rewards strong engineering; it doesn’t replace it. It’s an exciting time to be involved.
Join us at the Software Architecture Superstream on December 9 to learn how to better navigate the impact of AI on systems, processes, and governance. Over four hours, host Neal Ford and our lineup of experts including Metro Bank’s Anjali Jain and Philip O’Shaughnessy, Vercel’s Dom Sipowicz, Intel’s Brian Rogers, Microsoft’s Ron Abellera, and Equal Experts’ Lewis Crawford will share their hard-won insights about building adaptive, AI-ready architectures that support continuous innovation, ensure governance and security, and align seamlessly with business goals.
When AI systems were just a single model behind an API, life felt simpler. You trained, deployed, and maybe fine-tuned a few hyperparameters.
But that world’s gone. Today, AI feels less like a single engine and more like a busy city—a network of small, specialized agents constantly talking to each other, calling APIs, automating workflows, and making decisions faster than humans can even follow.
And here’s the real challenge: The smarter and more independent these agents get, the harder it becomes to stay in control. Performance isn’t what slows us down anymore. Governance is.
How do we make sure these agents act ethically, safely, and within policy? How do we log what happened when multiple agents collaborate? How do we trace who decided what in an AI-driven workflow that touches user data, APIs, and financial transactions?
That’s where the idea of engineering governance into the stack comes in. Instead of treating governance as paperwork at the end of a project, we can build it into the architecture itself.
From Model Pipelines to Agent Ecosystems
In the old days of machine learning, things were pretty linear. You had a clear pipeline: collect data, train the model, validate it, deploy, monitor. Each stage had its tools and dashboards, and everyone knew where to look when something broke.
But with AI agents, that neat pipeline turns into a web. A single customer-service agent might call a summarization agent, which then asks a retrieval agent for context, which in turn queries an internal API—all happening asynchronously, sometimes across different systems.
It’s less like a pipeline now and more like a network of tiny brains, all thinking and talking at once. And that changes how we debug, audit, and govern. When an agent accidentally sends confidential data to the wrong API, you can’t just check one log file anymore. You need to trace the whole story: which agent called which, what data moved where, and why each decision was made. In other words, you need full lineage, context, and intent tracing across the entire ecosystem.
Why Governance Is the Missing Layer
Governance in AI isn’t new. We already have frameworks like NIST’s AI Risk Management Framework (AI RMF) and the EU AI Act defining principles like transparency, fairness, and accountability. The problem is these frameworks often stay at the policy level, while engineers work at the pipeline level. The two worlds rarely meet. In practice, that means teams might comply on paper but have no real mechanism for enforcement inside their systems.
What we really need is a bridge—a way to turn those high-level principles into something that runs alongside the code, testing and verifying behavior in real time. Governance shouldn’t be another checklist or approval form; it should be a runtime layer that sits next to your AI agents—ensuring every action follows approved paths, every dataset stays where it belongs, and every decision can be traced when something goes wrong.
The Four Guardrails of Agent Governance
Policy as code
Policies shouldn’t live in forgotten PDFs or static policy docs. They should live next to your code. By using tools like the Open Policy Agent (OPA), you can turn rules into version-controlled code that’s reviewable, testable, and enforceable. Think of it like writing infrastructure as code, but for ethics and compliance. You can define rules such as:
Which agents can access sensitive datasets
Which API calls require human review
When a workflow needs to stop because the risk feels too high
This way, developers and compliance folks stop talking past each other—they work in the same repo, speaking the same language.
And the best part? You can spin up a Dockerized OPA instance right next to your AI agents inside your Kubernetes cluster. It just sits there quietly, watching requests, checking rules, and blocking anything risky before it hits your APIs or data stores.
Governance stops being some scary afterthought. It becomes just another microservice. Scalable. Observable. Testable. Like everything else that matters.
Observability and auditability
Agents need to be observable not just in performance terms (latency, errors) but in decision terms. When an agent chain executes, we should be able to answer:
Who initiated the action?
What tools were used?
What data was accessed?
What output was generated?
Modern observability stacks—Cloud Logging, OpenTelemetry, Prometheus, or Grafana Loki—can already capture structured logs and traces. What’s missing is semantic context: linking actions to intent and policy.
Imagine extending your logs to capture not only “API called” but also “Agent FinanceBot requested API X under policy Y with risk score 0.7.” That’s the kind of metadata that turns telemetry into governance.
When your system runs in Kubernetes, sidecar containers can automatically inject this metadata into every request, creating a governance trace as natural as network telemetry.
Dynamic risk scoring
Governance shouldn’t mean blocking everything; it should mean evaluating risk intelligently. In an agent network, different actions have different implications. A “summarize report” request is low risk. A “transfer funds” or “delete records” request is high risk.
By assigning dynamic risk scores to actions, you can decide in real time whether to:
Allow it automatically
Require additional verification
Escalate to a human reviewer
You can compute risk scores using metadata such as agent role, data sensitivity, and confidence level. Cloud providers like Google Cloud Vertex AI Model Monitoring already support risk tagging and drift detection—you can extend those ideas to agent actions.
The point isn’t to slow agents down but to make their behavior context-aware.
Regulatory mapping
Frameworks like NIST AI RMF and the EU AI Act are often seen as legal mandates. In reality, they can double as engineering blueprints.
Governance principle
Engineering implementation
Transparency
Agent activity logs, explainability metadata
Accountability
Immutable audit trails in Cloud Logging/Chronicle
Robustness
Canary testing, rollout control in Kubernetes
Risk management
Real-time scoring, human-in-the-loop review
Mapping these requirements into cloud and container tools turns compliance into configuration.
Once you start thinking of governance as a runtime layer, the next step is to design what that actually looks like in production.
Building a Governed AI Stack
Let’s visualize a practical, cloud native setup—something you could deploy tomorrow.
All of these can run on Kubernetes with Docker containers for modularity. The governance layer acts as a smart proxy—it intercepts agent calls, evaluates policy and risk, then logs and forwards the request if approved.
In practice:
Each agent’s container registers itself with the governance service.
Policies live in Git, deployed as ConfigMaps or sidecar containers.
Logs flow into Cloud Logging or Elastic Stack for searchable audit trails.
A Chronicle or BigQuery dashboard visualizes high-risk agent activity.
This separation of concerns keeps things clean: Developers focus on agent logic, security teams manage policy rules, and compliance officers monitor dashboards instead of sifting through raw logs. It’s governance you can actually operate—not bureaucracy you try to remember later.
Lessons from the Field
When I started integrating governance layers into multi-agent pipelines, I learned three things quickly:
It’s not about more controls—it’s about smarter controls. When all operations have to be manually approved, you will paralyze your agents. Focus on automating the 90% that’s low risk.
Logging everything isn’t enough. Governance requires interpretable logs. You need correlation IDs, metadata, and summaries that map events back to business rules.
Governance has to be part of the developer experience. If compliance feels like a gatekeeper, developers will route around it. If it feels like a built-in service, they’ll use it willingly.
In one real-world deployment for a financial-tech environment, we used a Kubernetes admission controller to enforce policy before pods could interact with sensitive APIs. Each request was tagged with a “risk context” label that traveled through the observability stack. The result? Governance without friction. Developers barely noticed it—until the compliance audit, when everything just worked.
Human in the Loop, by Design
Despite all the automation, people should also be involved in making some decisions. A healthy governance stack knows when to ask for help. Imagine a risk-scoring service that occasionally flags “Agent Alpha has exceeded transaction threshold three times today.” As an alternative to blocking, it may forward the request to a human operator via Slack or an internal dashboard. That is not a weakness but a good indication of maturity when an automated system requires a person to review it. Reliable AI does not imply eliminating people; it means knowing when to bring them back in.
Avoiding Governance Theater
Every company wants to say they have AI governance. But there’s a difference between governance theater—policies written but never enforced—and governance engineering—policies turned into running code.
When you can measure governance, you can improve it. That’s how you move from pretending to protect systems to proving that you do. The future of AI isn’t just about building smarter models; it’s about building smarter guardrails. Governance isn’t bureaucracy—it’s infrastructure for trust. And just as we’ve made automated testing part of every CI/CD pipeline, we’ll soon treat governance checks the same way: built in, versioned, and continuously improved.
True progress in AI doesn’t come from slowing down. It comes from giving it direction, so innovation moves fast but never loses sight of what’s right.
The Cyberspace Solarium Commission’s (CSC 2.0) annual implementation report has sparked fresh concern from representatives and cybersecurity leaders that U.S. cyber progress is slowing. Bureaucratic delays, budget constraints and uneven policy follow-through, particularly around the Cybersecurity and Infrastructure Security Agency’s authorities and funding, are all apparent.
But does this paint the full picture of the technical implementation and enforcement of U.S. cybersecurity? Hardly.
Beneath the policy layer, the technical and strategic modernization of U.S. cybersecurity is actually accelerating faster than ever. While there’s a lot of doom and gloom at the civilian policy level, it’s important we acknowledge the progress individual agencies have made and provide constructive steps to continue to capitalize on that progress.
A defining moment came with the finalization of the CMMC 2.0 rule, which is now effective and entered its first implementation phase on Nov. 10. More than 80,000 defense industrial base vendors will be required by contract to comply with rigorous cybersecurity controls aligned to NIST 800-171, with a hard assessment deadline in 2026.
CMMC 2.0 ensures that cybersecurity is no longer a checkbox exercise or a “nice-to-have” policy objective. It’s now a legal and contractual requirement. By the time full assessments begin in 2026, the Defense Department will have reshaped the entire DIB into a verified ecosystem of secure software and systems providers.
That’s a significant milestone that will set the stage for the operationalization of accountability for government technology.
Equally as transformative is the DoD’s quiet revolution in risk management. In September 2025, the DoD introduced its Cybersecurity Risk Management Construct (CRMC). This is a long-awaited, direct successor to the outdated, paperwork-heavy Risk Management Framework.
The new construct adopts the continuous authority to operate (cATO) model, enabling near-real-time monitoring and risk response. It’s a move away from static compliance documentation toward dynamic, data-driven assurance, reflecting the pace of modern software delivery.
The DoD’s transformation is being powered by the Software Fast Track (SWFT) initiative, launched in mid-2025 to modernize acquisition. SWFT brings DevSecOps automation directly into the authorization process, ensuring secure software can reach warfighters faster and without compromising security. It’s a fundamental shift from compliance to continuous validation.
Lastly, the CSC 2.0’s report doesn’t touch on the work being done by the National Institute of Standards and Technology to operationalize the AI Risk Management Framework for 2026. This will bring much-needed clarity to secure and responsible AI adoption across government and industry.
It’s easy to equate stalled legislation or delayed budgets with a lack of progress. But in cybersecurity, the most impactful advancements rarely happen in congressional hearings. They happen in codebases, acquisition reforms and audit protocols. The policy narrative may be sluggish, but in those areas, we are actually seeing healthy progress as the technical foundation of U.S. cyber defense is advancing rapidly.
Through CMMC enforcement, cATO adoption, automated software assurance and AI governance, federal cybersecurity is entering an implementation era where secure software supply chains and continuous monitoring are not aspirations, but expectations.
With all that said, does this mean the CSC 2.0’s findings should be ignored? Absolutely not.
The reality is that we don’t have a cybersecurity problem; we have an insecure software problem. By not driving forward policy at the civilian-level to change the economics in such a way that incentivizes ensuring the delivery of secure software, we may be ceding the very progress I just outlined.
However, to say “U.S. cyber progress stalls” is to overlook this reality. The truth is that 2025 marks the year where U.S. cybersecurity finally shifted from policy to practice.
Antoine Harden is the vice president of federal sales at Sonatype.
November ended. Thanksgiving (in the US), turkey, and a train of model announcements. The announcements were exciting: Google’s Gemini 3 puts it in the lead among large language models, at least for the time being. Nano Banana Pro is a spectacularly good text-to-image model. OpenAI has released its heavy hitters, GPT-5.1-Codex-Max and GPT-5.1 Pro. And the Allen Institute released its latest open source model, Olmo 3, the leading open source model from the US.
Since Trends avoids deal-making (should we?), we’ve also avoided the angst around an AI bubble and its implosion. Right now, it’s safe to say that the bubble is formed of money that hasn’t yet been invested, let alone spent. If it is a bubble, it’s in the future. Do promises and wishes make a bubble? Does a bubble made of promises and wishes pop with a bang or a pffft?
AI
Now that Google and OpenAI have laid down their cards, Anthropic has released its latest heavyweight model: Opus 4.5. They’ve also dropped the price significantly.
The Allen Institute has launched its latest open source model, Olmo 3. The institute’s opened up the whole development process to allow other teams to understand its work.
Not to be outdone, Google has introduced Nano Banana Pro (aka Gemini 3 Pro Image), its state-of-the-art image generation model. Nano Banana’s biggest feature is the ability to edit images to change the appearance of items without redrawing them from scratch. And according to Simon WIllison, it watermarks the parts of an image it generates with SynthID.
OpenAI has released two more components of GPT-5.1, GPT-5.1-Codex-Max (API) and GPT-5.1 Pro (ChatGPT). This release brings the company’s most powerful models for generative work into view.
A group of quantum physicists claim to have reduced the size of the DeepSeek model by half, and to have removed Chinese censorship. The model can now tell you what happened in Tiananmen Square, explain what Pooh looked like, and answer other forbidden questions.
The release train for Gemini 3 has begun, and the commentariatquicklycrownedit king of the LLMs. It includes the ability to spin up a web interface so users can give it more information about their questions, and to generate diagrams along with text output.
As part of the Gemini 3 release, Google has also announced a new agentic IDE called Antigravity.
Google has released a new weather forecasting model, WeatherNext 2, that can forecast with resolutions up to 1 hour. The data is available through Earth Engine and BigQuery, for those who would like to do their own forecasting. There’s also an early access program on Vertex AI.
Grok 4.1 has been released, with reports that it is currently the best model at generative prose, including creative writing. Be that as it may, we don’t see why anyone would use an AI that has been trained to reflect Elon Musk’s thoughts and values. If AI has taught us one thing, it’s that we need to think for ourselves.
AI demands the creation of new data centers and new energy sources. States want to ensure that those power plants are built, and built in ways that don’t pass costs on to consumers.
Grokipedia uses questionable sources. Is anyone surprised? How else would you train an AI on the latest conspiracy theories?
AMD GPUs are competitive, but they’re hampered because there are few libraries for low-level operations. To solve this problem, Chris Ré and others have announcedHipKittens, a library of programming primitive operations for AMD GPUs.
OpenAI has released GPT-5.1. The two new models are Instant, which is tuned to be more conversational and “human,” and Thinking, a reasoning model that now adapts the time it takes to “think” to the difficulty of the questions.
Large language models, including GPT-5 and the Chinese models, show bias against users who use a German dialect rather than standard German. The bias appeared to be greater as the model size increased. These results also apply to languages like English.
Yann LeCun is leaving Facebook to launch a new startup that will develop his ideas about building AI.
Harbor is a new tool that simplifies benchmarking frameworks and models. It’s from the developers of the Terminal-Bench benchmark. And it brings us a step closer to a world where people build their own specialized AI rather than rely on large providers.
Moonshot AI has finally releasedKimiK2 Thinking, the first open weights model to have benchmark results competitive with—or exceeding—the best closed weights models. It’s designed to be used as an agent, calling external tools as needed to solve problems.
Tongyi DeepResearch is a new fully open source agent for doing research. Its results are comparable to OpenAI deep research, Claude Sonnet 4, and similar models. Tongyi is part of Alibaba; it’s yet another important model to come out of China.
MiniMax M2 is a new open weights model that focuses on building agents. It has performance similar to Claude Sonnet but at a much lower price point. It also embeds its thought processes between <think> and </think> tags, which is an important step toward interpretability.
DeepSeek has introduced a new model for OCR with some very interesting properties: It has a new process for storing and retrieving memories that also makes the model significantly more efficient.
Agent Lightning provides a code-free way to train agents using reinforcement learning.
Programming
The Zig programming language has published a book. Online, of course.
Google is weakening its controversial new rules about developer verification. The company plans to create a separate class for applications with limited distribution, and develop a flow that will allow the installation of unverified apps.
Google’s LiteRT is a library for running AI models in browsers and small devices. LiteRT supports Android, iOS, embedded Linux, and microcontrollers. Supported languages include Java, Kotlin, Swift, Embedded C, and C++.
Does AI-assisted coding mean the end of new languages? Simon Willison thinks that LLMs can encourage the development of new programming languages. Design your language and ship it with a Claude Skills-style document; that should be enough for an LLM to learn how to use it.
Deepnote, a successor to the Jupyter Notebook, is a next-generation notebook for data analytics that’s built for teams. There’s now a shared workspace; different blocks can use different languages; and AI integration is on the road map. It’s now open source.
The idea of assigning colors (red, blue) to tools may be helpful in limiting the risk of prompt injection when building agents. What tools can return something damaging? This sounds like a step towards the application of the “least privilege” principle to AI design.
Security
We’re making the same mistake with AI security as we made with cloud security (and security in general): treating security as an afterthought.
Don’t become a victim. Data collected for online age verification makes your site a target for attackers. That data is valuable, and they know it.
A research collaboration uses data poisoning and AI to disrupt deepfake images. Users use Silverer to process their images before posting. The tool makes invisible changes to the original image that confuse AIs creating new images, leading to unusable distortions.
Is it a surprise that AI is being used to generate fake receipts and expense reports? After all, it’s used to fake just about everything else. It was inevitable that enterprise applications of AI fakery would appear.
HydraPWK2 is a Linux distribution designed for penetration testing. It’s based on Debian and is supposedly easier to use than Kali Linux.
How secure is your trusted execution environment (TEE)? All of the major hardware vendors are vulnerable to a number of physical attacks against “secure enclaves.” And their terms of service often exclude physical attacks.
Atroposia is a new malware-as-a-service package that includes a local vulnerability scanner. Once an attacker has broken into a site, they can find other ways to remain there.
A new kind of phishing attack (CoPhishing) uses Microsoft Copilot Studio agents to steal credentials by abusing the Sign In topic. Microsoft has promised an update that will defend against this attack.
Operations
Here’s how to install Open Notebook, an open source equivalent to NotebookLM, to run on your own hardware. It uses Docker and Ollama to run the notebook and the model locally, so data never leaves your system.
Open source isn’t “free as in beer.” Nor is it “free as in freedom.” It’s “free as in puppies.” For better or for worse, that just about says it.
Need a framework for building proxies? Cloudflare’s next generation Oxy framework might be what you need. (Whatever you think of their recent misadventure.)
MIT Media Labs’ Project NANDA intends to build infrastructure for a decentralized network of AI agents. They describe it as a global decentralized registry (not unlike DNS) that can be used to discover and authenticate agents using MCP and A2A. Isn’t this what we wanted from the internet in the first place?
Luke Wroblewski suggests a new model for designing AI chat sessions. A simple chat isn’t as simple as it seems; particularly with reasoning models, it can become cluttered to the point of uselessness. This new design addresses those problems.
The debate about open source AI has largely featured open weight models. But that’s a bit like arguing that in the PC era, the most important goal would have been to have Intel open source its chip designs. That might have been useful to some people, but it wouldn’t have created Linux, Apache, or the collaborative software ecosystem that powers the modern internet. What makes open source transformative is the ease with which people can learn from what others have done, modify it to meet their own needs, and share those modifications with others. And that can’t just happen at the lowest, most complex level of a system. And it doesn’t come easily when what you are providing is access to a system that takes enormous resources to modify, use, and redistribute. It comes from what I’ve called the architecture of participation.
This architecture of participation has a few key properties:
Legibility: You can understand what a component does without understanding the whole system.
Modifiability: You can change one piece without rewriting everything.
Composability: Pieces work together through simple, well-defined interfaces.
Shareability: Your small contribution can be useful to others without them adopting your entire stack.
The most successful open source projects are built from small pieces that work together. Unix gave us a small operating system kernel surrounded by a library of useful functions, together with command-line utilities that could be chained together with pipes and combined into simple programs using the shell. Linux followed and extended that pattern. The web gave us HTML pages you could “view source” on, letting anyone see exactly how a feature was implemented and adapt it to their needs, and HTTP connected every website as a linkable component of a larger whole. Apache didn’t beat Netscape and Microsoft in the web server market by adding more and more features, but instead provided an extension layer so a community of independent developers could add frameworks like Grails, Kafka, and Spark.
MCP and Skills Are “View Source” for AI
MCP and Claude Skills remind me of those early days of Unix/Linux and the web. MCP lets you write small servers that give AI systems new capabilities such as access to your database, your development tools, your internal APIs, or third-party services like GitHub, GitLab, or Stripe. A skill is even more atomic: a set of plain language instructions, often with some tools and resources, that teaches Claude how to do something specific. Matt Bell from Anthropic remarked in comments on a draft of this piece that a skill can be defined as “the bundle of expertise to do a task, and is typically a combination of instructions, code, knowledge, and reference materials.” Perfect.
What is striking about both is their ease of contribution. You write something that looks like the shell scripts and web APIs developers have been writing for decades. If you can write a Python function or format a Markdown file, you can participate.
This is the same quality that made the early web explode. When someone created a clever navigation menu or form validation, you could view source, copy their HTML and JavaScript, and adapt it to your site. You learned by doing, by remixing, by seeing patterns repeated across sites you admired. You didn’t have to be an Apache contributor to get the benefit of learning from others and reusing their work.
Anthropic’s MCP Registry and third-party directories like punkpeye/awesome-mcp-servers show early signs of this same dynamic. Someone writes an MCP server for Postgres, and suddenly dozens of AI applications gain database capabilities. Someone creates a skill for analyzing spreadsheets in a particular way, and others fork it, modify it, and share their versions. Anthropic still seems to be feeling its way with user contributed skills, listing in its skills gallery only those they and select partners have created, but they document how to create them, making it possible for anyone to build a reusable tool based on their specific needs, knowledge, or insights. So users are developing skills that make Claude more capable and sharing them via GitHub. It will be very exciting to see how this develops. Groups of developers with shared interests creating and sharing collections of interrelated skills and MCP servers that give models deep expertise in a particular domain will be a potent frontier for both AI and open source.
GPTs Versus Skills: Two Models of Extension
It’s worth contrasting the MCP and skills approach with OpenAI’s custom GPTs, which represent a different vision of how to extend AI capabilities.
GPTs are closer to apps. You create one by having a conversation with ChatGPT, giving it instructions and uploading files. The result is a packaged experience. You can use a GPT or share it for others to use, but they can’t easily see how it works, fork it, or remix pieces of it into their own projects. GPTs live in OpenAI’s store, discoverable and usable but ultimately contained within the OpenAI ecosystem.
This is a valid approach, and for many use cases, it may be the right one. It’s user-friendly. If you want to create a specialized assistant for your team or customers, GPTs make that straightforward.
But GPTs aren’t participatory in the open source sense. You can’t “view source” on someone’s GPT to understand how they got it to work well. You can’t take the prompt engineering from one GPT and combine it with the file handling from another. You can’t easily version control GPTs, diff them, or collaborate on them the way developers do with code. (OpenAI offers team plans that do allow collaboration by a small group using the same workspace, but this is a far cry from open source–style collaboration.)
Skills and MCP servers, by contrast, are files and code. A skill is literally just a Markdown document you can read, edit, fork, and share. An MCP server is a GitHub repository you can clone, modify, and learn from. They’re artifacts that exist independently of any particular AI system or company.
This difference matters. The GPT Store is an app store, and however rich it becomes, an app store remains a walled garden. The iOS App Store and Google Play store host millions of apps for phones, but you can’t view source on an app, can’t extract the UI pattern you liked, and can’t fork it to fix a bug the developer won’t address. The open source revolution comes from artifacts you can inspect, modify, and share: source code, markup languages, configuration files, scripts. These are all things that are legible not just to computers but to humans who want to learn and build.
That’s the lineage skills and MCP belong to. They’re not apps; they’re components. They’re not products; they’re materials. The difference is architectural, and it shapes what kind of ecosystem can grow around them.
Nothing prevents OpenAI from making GPTs more inspectable and forkable, and nothing prevents skills or MCP from becoming more opaque and packaged. The tools are young. But the initial design choices reveal different instincts about what kind of participation matters. OpenAI seems deeply rooted in the proprietary platform model. Anthropic seems to be reaching for something more open.1
Complexity and Evolution
Of course, the web didn’t stay simple. HTML begat CSS, which begat JavaScript frameworks. View source becomes less useful when a page is generated by megabytes of minified React.
But the participatory architecture remained. The ecosystem became more complex, but it did so in layers, and you can still participate at whatever layer matches your needs and abilities. You can write vanilla HTML, or use Tailwind, or build a complex Next.js app. There are different layers for different needs, but all are composable, all shareable.
I suspect we’ll see a similar evolution with MCP and skills. Right now, they’re beautifully simple. They’re almost naive in their directness. That won’t last. We’ll see:
Abstraction layers: Higher-level frameworks that make common patterns easier.
Composition patterns: Skills that combine other skills, MCP servers that orchestrate other servers.
Optimization: When response time matters, you might need more sophisticated implementations.
Security and safety layers: As these tools handle sensitive data and actions, we’ll need better isolation and permission models.
The question is whether this evolution will preserve the architecture of participation or whether it will collapse into something that only specialists can work with. Given that Claude itself is very good at helping users write and modify skills, I suspect that we are about to experience an entirely new frontier of learning from open source, one that will keep skill creation open to all even as the range of possibilities expands.
What Does This Mean for Open Source AI?
Open weights are necessary but not sufficient. Yes, we need models whose parameters aren’t locked behind APIs. But model weights are like processor instructions. They are important but not where the most innovation will happen.
The real action is at the interface layer. MCP and skills open up new possibilities because they create a stable, comprehensible interface between AI capabilities and specific uses. This is where most developers will actually participate. Not only that, it’s where people who are not now developers will participate, as AI further democratizes programming. At bottom, programming is not the use of some particular set of “programming languages.” It is the skill set that starts with understanding a problem that the current state of digital technology can solve, imagining possible solutions, and then effectively explaining to a set of digital tools what we want them to help us do. The fact that this may now be possible in plain language rather than a specialized dialect means that more people can create useful solutions to the specific problems they face rather than looking only for solutions to problems shared by millions. This has always been a sweet spot for open source. I’m sure many people have said this about the driving impulse of open source, but I first heard it from Eric Allman, the creator of Sendmail, at what became known as the open source summit in 1998: “scratching your own itch.” And of course, history teaches us that this creative ferment often leads to solutions that are indeed useful to millions. Amateur programmers become professionals, enthusiasts become entrepreneurs, and before long, the entire industry has been lifted to a new level.
Standards enable participation. MCP is a protocol that works across different AI systems. If it succeeds, it won’t be because Anthropic mandates it but because it creates enough value that others adopt it. That’s the hallmark of a real standard.
Ecosystems beat models. The most generative platforms are those in which the platform creators are themselves part of the ecosystem. There isn’t an AI “operating system” platform yet, but the winner-takes-most race for AI supremacy is based on that prize. Open source and the internet provide an alternate, standards-based platform that not only allows people to build apps but to extend the platform itself.
Open source AI means rethinking open source licenses. Most of the software shared on GitHub has no explicit license, which means that default copyright laws apply: The software is under exclusive copyright, and the creator retains all rights. Others generally have no right to reproduce, distribute, or create derivative works from the code, even if it is publicly visible on GitHub. But as Shakespeare wrote in The Merchant of Venice, “The brain may devise laws for the blood, but a hot temper leaps o’er a cold decree.” Much of this code is de facto open source, even if not de jure. People can learn from it, easily copy from it, and share what they’ve learned.
But perhaps more importantly for the current moment in AI, it was all used to train LLMs, which means that this de facto open source code became a vector through which all AI-generated code is created today. This, of course, has made many developers unhappy, because they believe that AI has been trained on their code without either recognition or recompense. For open source, recognition has always been a fundamental currency. For open source AI to mean something, we need new approaches to recognizing contributions at every level.
Licensing issues also come up around what happens to data that flows through an MCP server. What happens when people connect their databases and proprietary data flows through an MCP so that an LLM can reason about it? Right now I suppose it falls under the same license as you have with the LLM vendor itself, but will that always be true? And, would I, as a provider of information, want to restrict the use of an MCP server depending on a specific configuration of a user’s LLM settings? For example, might I be OK with them using a tool if they have turned off “sharing” in the free version, but not want them to use it if they hadn’t? As one commenter on a draft of this essay put it, “Some API providers would like to prevent LLMs from learning from data even if users permit it. Who owns the users’ data (emails, docs) after it has been retrieved via a particular API or MCP server might be a complicated issue with a chilling effect on innovation.”
There are efforts such as RSL (Really Simple Licensing) and CC Signals that are focused on content licensing protocols for the consumer/open web, but they don’t yet really have a model for MCP, or more generally for transformative use of content by AI. For example, if an AI uses my credentials to retrieve academic papers and produces a literature review, what encumbrances apply to the results? There is a lot of work to be done here.
Open Source Must Evolve as Programming Itself Evolves
It’s easy to be amazed by the magic of vibe coding. But treating the LLM as a code generator that takes input in English or other human languages and produces Python, TypeScript, or Java echoes the use of a traditional compiler or interpreter to generate byte code. It reads what we call a “higher-level language” and translates it into code that operates further down the stack. And there’s a historical lesson in that analogy. In the early days of compilers, programmers had to inspect and debug the generated assembly code, but eventually the tools got good enough that few people need to do that any more. (In my own career, when I was writing the manual for Lightspeed C, the first C compiler for the Mac, I remember Mike Kahl, its creator, hand-tuning the compiler output as he was developing it.)
Now programmers are increasingly finding themselves having to debug the higher-level code generated by LLMs. But I’m confident that will become a smaller and smaller part of the programmer’s role. Why? Because eventually we come to depend on well-tested components. I remember how the original Macintosh user interface guidelines, with predefined user interface components, standardized frontend programming for the GUI era, and how the Win32 API meant that programmers no longer needed to write their own device drivers. In my own career, I remember working on a book about curses, the Unix cursor-manipulation library for CRT screens, and a few years later the manuals for Xlib, the low-level programming interfaces for the X Window System. This kind of programming soon was superseded by user interface toolkits with predefined elements and actions. So too, the roll-your-own era of web interfaces was eventually standardized by powerful frontend JavaScript frameworks.
Once developers come to rely on libraries of preexisting components that can be combined in new ways, what developers are debugging is no longer the lower-level code (first machine code, then assembly code, then hand-built interfaces) but the architecture of the systems they build, the connections between the components, the integrity of the data they rely on, and the quality of the user interface. In short, developers move up the stack.
LLMs and AI agents are calling for us to move up once again. We are groping our way towards a new paradigm in which we are not just building MCPs as instructions for AI agents but developing new programming paradigms that blend the rigor and predictability of traditional programming with the knowledge and flexibility of AI. As Phillip Carter memorably noted, LLMs are inverted computers relative to those with which we’ve been familiar: “We’ve spent decades working with computers that are incredible at precision tasks but need to be painstakingly programmed for anything remotely fuzzy. Now we have computers that are adept at fuzzy tasks but need special handling for precision work.” That being said, LLMs are becoming increasingly adept at knowing what they are good at and what they aren’t. Part of the whole point of MCP and skills is to give them clarity about how to use the tools of traditional computing to achieve their fuzzy aims.
Consider the evolution of agents from those based on “browser use” (that is, working with the interfaces designed for humans) to those based on making API calls (that is, working with the interfaces designed for traditional programs) to those based on MCP (relying on the intelligence of LLMs to read documents that explain the tools that are available to do a task). An MCP server looks a lot like the formalization of prompt and context engineering into components. A look at what purports to be a leaked system prompt for ChatGPT suggests that the pattern of MCP servers was already hidden in the prompts of proprietary AI apps: “Here’s how I want you to act. Here are the things that you should and should not do. Here are the tools available to you.”
But while system prompts are bespoke, MCP and skills are a step towards formalizing plain text instructions to an LLM so that they can become reusable components. In short, MCP and skills are early steps towards a system of what we can call “fuzzy function calls.”
Fuzzy Function Calls: Magic Words Made Reliable and Reusable
This view of how prompting and context engineering fit with traditional programming connects to something I wrote about recently: LLMs natively understand high-level concepts like “plan,” “test,” and “deploy”; industry standard terms like “TDD” (Test Driven Development) or “PRD” (Product Requirements Document); competitive features like “study mode”; or specific file formats like “.md file.” These “magic words” are prompting shortcuts that bring in dense clusters of context and trigger particular patterns of behavior that have specific use cases.
But right now, these magic words are unmodifiable. They exist in the model’s training, within system prompts, or locked inside proprietary features. You can use them if you know about them, and you can write prompts to modify how they work in your current session. But you can’t inspect them to understand exactly what they do, you can’t tweak them for your needs, and you can’t share your improved version with others.
Skills and MCPs are a way to make magic words visible and extensible. They formalize the instructions and patterns that make an LLM application work, and they make those instructions something you can read, modify, and share.
Take ChatGPT’s study mode as an example. It’s a particular way of helping someone learn, by asking comprehension questions, testing understanding, and adjusting difficulty based on responses. That’s incredibly valuable. But it’s locked inside ChatGPT’s interface. You can’t even access it via the ChatGPT API. What if study mode was published as a skill? Then you could:
See exactly how it works. What instructions guide the interaction?
Modify it for your subject matter. Maybe study mode for medical students needs different patterns than study mode for language learning.
Fork it into variants. You might want a “Socratic mode” or “test prep mode” that builds on the same foundation.
Use it with your own content and tools. You might combine it with an MCP server that accesses your course materials.
Share your improved version and learn from others’ modifications.
This is the next level of AI programming “up the stack.” You’re not training models or vibe coding Python. You’re elaborating on concepts the model already understands, more adapted to specific needs, and sharing them as building blocks others can use.
Building reusable libraries of fuzzy functions is the future of open source AI.
The Economics of Participation
There’s a deeper pattern here that connects to a rich tradition in economics: mechanism design. Over the past few decades, economists like Paul Milgrom and Al Roth won Nobel Prizes for showing how to design better markets: matching systems for medical residents, spectrum auctions for wireless licenses, kidney exchange networks that save lives. These weren’t just theoretical exercises. They were practical interventions that created more efficient, more equitable outcomes by changing the rules of the game.
Some tech companies understood this. As chief economist at Google, Hal Varian didn’t just analyze ad markets, he helped design the ad auction that made Google’s business model work. At Uber, Jonathan Hall applied mechanism design insights to dynamic pricing and marketplace matching to build a “thick market” of passengers and drivers. These economists brought economic theory to bear on platform design, creating systems where value could flow more efficiently between participants.
Though not guided by economists, the web and the open source software revolution were also not just technical advances but breakthroughs in market design. They created information-rich, participatory markets where barriers to entry were lowered. It became easier to learn, create, and innovate. Transaction costs plummeted. Sharing code or content went from expensive (physical distribution, licensing negotiations) to nearly free. Discovery mechanisms emerged: Search engines, package managers, and GitHub made it easy to find what you needed. Reputation systems were discovered or developed. And of course, network effects benefited everyone. Each new participant made the ecosystem more valuable.
These weren’t accidents. They were the result of architectural choices that made internet-enabled software development into a generative, participatory market.
AI desperately needs similar breakthroughs in mechanism design. Right now, most economic analysis of AI focuses on the wrong question: “How many jobs will AI destroy?” This is the mindset of an extractive system, where AI is something done to workers and to existing companies rather than with them. The right question is: “How do we design AI systems that create participatory markets where value can flow to all contributors?”
Consider what’s broken right now:
Attribution is invisible. When an AI model benefits from training on someone’s work, there’s no mechanism to recognize or compensate for that contribution.
Value capture is concentrated. A handful of companies capture the gains, while millions of content creators, whose work trained the models and are consulted during inference, see no return.
Improvement loops are closed. If you find a better way to accomplish a task with AI, you can’t easily share that improvement or benefit from others’ discoveries.
Quality signals are weak. There’s no good way to know if a particular skill, prompt, or MCP server is well-designed without trying it yourself.
MCP and skills, viewed through this economic lens, are early-stage infrastructure for a participatory AI market. The MCP Registry and skills gallery are primitive but promising marketplaces with discoverable components and inspectable quality. When a skill or MCP server is useful, it’s a legible, shareable artifact that can carry attribution. While this may not redress the “original sin” of copyright violation during model training, it does perhaps point to a future where content creators, not just AI model creators and app developers, may be able to monetize their work.
But we’re nowhere near having the mechanisms we need. We need systems that efficiently match AI capabilities with human needs, that create sustainable compensation for contribution, that enable reputation and discovery, that make it easy to build on others’ work while giving them credit.
This isn’t just a technical challenge. It’s a challenge for economists, policymakers, and platform designers to work together on mechanism design. The architecture of participation isn’t just a set of values. It’s a powerful framework for building markets that work. The question is whether we’ll apply these lessons of open source and the web to AI or whether we’ll let AI become an extractive system that destroys more value than it creates.
A Call to Action
I’d love to see OpenAI, Google, Meta, and the open source community develop a robust architecture of participation for AI.
Make innovations inspectable. When you build a compelling feature or an effective interaction pattern or a useful specialization, consider publishing it in a form others can learn from. Not as a closed app or an API to a black box but as instructions, prompts, and tool configurations that can be read and understood. Sometimes competitive advantage comes from what you share rather than what you keep secret.
Support open protocols. MCP’s early success demonstrates what’s possible when the industry rallies around an open standard. Since Anthropic introduced it in late 2024, MCP has been adopted by OpenAI (across ChatGPT, the Agents SDK, and the Responses API), Google (in the Gemini SDK), Microsoft (in Azure AI services), and a rapidly growing ecosystem of development tools from Replit to Sourcegraph. This cross-platform adoption proves that when a protocol solves real problems and remains truly open, companies will embrace it even when it comes from a competitor. The challenge now is to maintain that openness as the protocol matures.
Create pathways for contribution at every level. Not everyone needs to fork model weights or even write MCP servers. Some people should be able to contribute a clever prompt template. Others might write a skill that combines existing tools in a new way. Still others will build infrastructure that makes all of this easier. All of these contributions should be possible, visible, and valued.
Document magic. When your model responds particularly well to certain instructions, patterns, or concepts, make those patterns explicit and shareable. The collective knowledge of how to work effectively with AI shouldn’t be scattered across X threads and Discord channels. It should be formalized, versioned, and forkable.
Reinvent open source licenses. Take into account the need for recognition not only during training but inference. Develop protocols that help manage rights for data that flows through networks of AI agents.
Engage with mechanism design. Building a participatory AI market isn’t just a technical problem, it’s an economic design challenge. We need economists, policymakers, and platform designers collaborating on how to create sustainable, participatory markets around AI. Stop asking “How many jobs will AI destroy?” and start asking “How do we design AI systems that create value for all participants?” The architecture choices we make now will determine whether AI becomes an extractive force or an engine of broadly shared prosperity.
The future of programming with AI won’t be determined by who publishes model weights. It’ll be determined by who creates the best ways for ordinary developers to participate, contribute, and build on each other’s work. And that includes the next wave of developers: users who can create reusable AI skills based on their special knowledge, experience, and human perspectives.
We’re at a choice point. We can make AI development look like app stores and proprietary platforms, or we can make it look like the open web and the open source lineages that descended from Unix. I know which future I’d like to live in.
Footnotes
I shared a draft of this piece with members of the Anthropic MCP and Skills team, and in addition to providing a number of helpful technical improvements, they confirmed a number of points where my framing captured their intentions. Comments ranged from “Skills were designed with composability in mind. We didn’t want to confine capable models to a single system prompt with limited functions” to “I love this phrasing since it leads into considering the models as the processing power, and showcases the need for the open ecosystem on top of the raw power a model provides” and “In a recent talk, I compared the models to processors, agent runtimes/orchestrations to the OS, and Skills as the application.” However, all of the opinions are my own and Anthropic is not responsible for anything I’ve said here.
Federal agencies face an ever-evolving threat landscape, with cyberattacks escalating in both frequency and sophistication. To keep pace, advancing digital modernization isn’t just an aspiration; it’s a necessity. Central to this effort is the Trusted Internet Connections (TIC) 3.0 initiative, which offers agencies a transformative approach to secure and modernize their IT infrastructure.
TIC 3.0 empowers agencies with the flexibility to securely access applications, data and the internet, providing them with the tools they need to enhance their cyber posture and meet the evolving security guidance from the Office of Management and Budget and the Cybersecurity and Infrastructure Security Agency. Yet, despite these advantages, many agencies are still operating under the outdated TIC 2.0 model, which creates persistent security gaps, slows user experience, and drives higher operating costs, ultimately hindering progress toward today’s modernization and adaptive security goals.
Why agencies must move beyond TIC 2.0
TIC 2.0, introduced over a decade ago, aimed to consolidate federal agencies’ internet connections through a limited number of TIC access points. These access points were equipped with legacy, inflexible and costly perimeter defenses, including firewalls, web proxies, traffic inspection tools and intrusion detection systems, designed to keep threats out. While effective for their time, these static controls weren’t designed for today’s cloud-first, mobile workforce. Often referred to as a “castle and moat” architecture, this perimeter-based security model was effective when TIC 2.0 first came out, but is now outdated and insufficient against today’s dynamic threat landscape.
Recognizing these limitations, OMB introduced TIC 3.0 in 2019 to better support the cybersecurity needs of a mobile, cloud-connected workforce. TIC 3.0 facilitates agencies’ transition from traditional perimeter-based solutions, such as Managed Trusted Internet Protocol Service (MTIPS) and legacy VPNs, to modern Secure Access Service Edge (SASE) and Security Service Edge (SSE) frameworks. This new model brings security closer to the user and the data, improving performance, scalability and visibility across hybrid environments.
The inefficiencies of TIC 2.0
In addition to the inefficiencies of a “castle and moat” architecture, TIC 2.0 presents significant trade-offs for agencies operating in hybrid and multi-cloud environments:
Latency on end users: TIC 2.0 moves data to where the security is located, rather than positioning security closer to where the data resides. This slows performance, hampers visibility, and frustrates end users.
Legacy systems challenges: outdated hardware and rigid network paths prevent IT teams from managing access dynamically. While modern technologies deliver richer visibility and stronger data protection, legacy architectures hold agencies back from adopting them at scale.
Outages and disruptions: past TIC iterations often struggle to integrate cloud services with modern security tools. This can create bottlenecks and downtime that disrupt operations and delay modernization efforts.
TIC 3.0 was designed specifically to overcome these challenges, offering a more flexible, distributed framework that aligns with modern security and mission requirements.
“TIC tax” on agencies — and users
TIC 2.0 also results in higher operational and performance costs. Since TIC 2.0 relies on traditional perimeter-based solutions — such as legacy VPNs, expensive private circuits and inflexible, vulnerable firewall stacks — agencies often face additional investments to maintain these outdated systems, a burden commonly referred to as the “TIC Tax.”
But the TIC Tax isn’t just financial. It also shows up in hidden costs to the end user. Under TIC 2.0, network traffic must be routed through a small number of approved TIC Access Points, most of which are concentrated around Washington, D.C. As a result, a user on the West Coast or at an embassy overseas may find their traffic backhauled thousands of miles before reaching its destination.
In an era where modern applications are measured in milliseconds, those delays translate into lost productivity, degraded user experience, and architectural inefficiency. What many users don’t realize is that a single web session isn’t just one exchange; it’s often thousands of tiny connections constantly flowing between the user’s device and the application server. Each of those interactions takes time, and when traffic must travel back and forth across the country — or around the world — the cumulative delay becomes a real, felt cost for the end user.
Every detour adds friction, not only for users trying to access applications, but also for security teams struggling to manage complex routing paths that no longer align with how distributed work and cloud-based systems operate. That’s why OMB, CISA and the General Services Administration have worked together under TIC 3.0 to modernize connectivity, eliminating the need for backhauling and enabling secure, direct-to-cloud options that prioritize both performance and protection.
For example, agencies adopting TIC 3.0 can leverage broadband internet services (BIS), a lower-cost, more flexible transport option that connects users directly to agency networks and cloud services through software-defined wide area network (SD-WAN) and SASE solutions.
With BIS, agencies are no longer constrained to rely on costly, fixed point-to-point or MPLS circuits to connect branch offices, data centers, headquarters and cloud environments. Instead, they can securely leverage commercial internet services to simplify connectivity, improve resiliency, and accelerate access to applications. This approach not only reduces operational expenses but also minimizes latency, supports zero trust principles, and enables agencies to build a safe, flexible and repeatable solution that meets TIC security objectives without taxing the user experience.
How TIC 2.0 hinders zero trust progress
Another inefficiency — and perhaps one of the most significant — of TIC 2.0 is its incompatibility with zero trust principles. As federal leaders move into the next phase of zero trust, focused on efficiency, automation and rationalizing cyber investments, TIC 2.0’s limitations are even more apparent.
Under TIC 2.0’s “castle and moat” model, all traffic, whether for email, web services or domain name systems, must be routed through a small number of geographically constrained access points. TIC 3.0, in contrast, adopts a decentralized model that leverages SASE and SSE platforms to enforce policy closer to the user and data source, improving both security and performance.
To visualize the difference, think of entering a baseball stadium. Under TIC 2.0’s “castle and moat” approach, once you show your ticket at the entrance, you can move freely throughout the stadium. TIC 3.0’s decentralized approach still checks your ticket, but ushers and staff ensure you stay in the right section, verifying continuously rather than once.
At its core, TIC 3.0 is about moving trust decisions closer to the resource. Unlike TIC 2.0, where data must travel to centralized security stacks, TIC 3.0 brings enforcement to the edge, closer to where users, devices and workloads actually reside. This aligns directly with zero trust principles of continuous verification, least privilege access and minimized attack surface.
How TIC 3.0 addresses TIC 2.0 inefficiencies
By decentralizing security and embracing SASE-based architectures, TIC 3.0 reduces latency, increases efficiency and enables agencies to apply modern cybersecurity practices more effectively. It gives system owners better visibility and control over network operations while allowing IT teams to manage threats in real time. The result is smoother, faster and more resilient user experiences.
With TIC 3.0, agencies can finally break free from the limitations of earlier TIC iterations. This modern framework not only resolves past inefficiencies, it creates a scalable, cloud-first foundation that evolves with emerging threats and technologies. TIC 3.0 supports zero trust priorities around integration, efficiency and rationalized investment, helping agencies shift from maintaining legacy infrastructure to enabling secure digital transformation.
Federal IT modernization isn’t just about replacing technology; it’s about redefining trust, performance and resilience for a cloud-first world. TIC 3.0 provides the framework, but true transformation comes from operationalizing that framework through platforms that are global, scalable, and adaptive to mission needs.
By extending security to where users and data truly live — at the edge — agencies can modernize without compromise: improving performance while advancing zero trust maturity. In that vision, TIC 3.0 isn’t simply an evolution of policy; it’s the foundation for how the federal enterprise securely connects to the future.
Sean Connelly is executive director for global zero trust strategy and policy at Zscaler and former zero trust initiative director and TIC program manager at CISA.
Today’s evolving financial landscape requires organizations to transform obsolete systems into future-ready infrastructures. Financial systems in particular need to align with compliance standards. The shift from reactive problem-solving to proactive transformation involves eliminating redundancies, automating processes, embedding analytics, integrating cloud platforms, enhancing data interoperability and adopting zero trust cybersecurity.
Here are eight best practices for implementing automation technology or taking on any modernization challenge:
Lead with people-centric change management. No technology or solution will work without day one buy-in from the people who will use it. Communication at every step sets the stage for success. Flow charts and brainstorming sessions with key stakeholders allow managers to talk through a workflow that addresses everyone’s needs. Touch points and progress updates keep stakeholders informed, and robust user training ensures adoption and mission alignment.
Streamline processes before you digitize. In a federal financial system, it’s common for accounts payable and receivable operations to function in isolation. A rigorous analysis sets the stage for creating a more efficient workflow that eliminates redundancy and obsolete manual processes. It’s essential to study the policies and procedures that guide workflows in manual or legacy systems and translate them to intelligent automation technology. Here, it’s often helpful to look at other federal agencies to see what has worked and lessons learned.
Automate intelligently to enhance mission focus. Automation for its own sake goes nowhere. It must be targeted not just to cut costs but also to free up the skilled federal workforce from repetitive, low-value tasks better suited for machine learning. Once liberated by artificial intelligence and automation, workers can focus on high-level analysis, strategic planning, and mission-critical objectives.
Mandate data interoperability for a single source of truth. In too many cases, one set of information does not connect to or integrate with another. Worse than these data silos are manual processes. Employees often work offline from Excel spreadsheets, making it even tougher to integrate the operations of federal agencies. Modernized core systems allow for the secure, seamless sharing of data to drive cross-agency collaboration, ensure comprehensive reporting and guarantee accurate analytics.
Embed analytics to drive proactive decision-making. Why look behind when you can look ahead? Cleaner financial statements stem from real-time, predictive insights. Upgraded systems integrate dashboards, data visualizations, reports and other forms of business intelligence. Their streamlined views empower leaders to anticipate future needs and challenges.
Build on a secure and scalable cloud framework. Rather than stack new technology on an obsolete core, cloud computing systems evolve as technology improves and make enhanced cybersecurity possible. What’s more, cloud technology can scale to handle massive data loads, integrate new tools and provide superior accessibility that a modern federal workforce demands.
Secure by design with a zero trust architecture. In the current threat landscape, security cannot be an afterthought. In a zero trust environment, no external data or outsider enters a system and third parties are granted access only after a thorough vetting. Continuous authentication is crucial. To work across systems, data scientists and data miners will extract only what is needed and clean the data first.
Develop your battle plan. Just as in the military, proactive transformation requires a clear, strategic roadmap. Follow these steps to produce a battle plan unique to your organization’s needs and challenges:
Conduct a comprehensive assessment. Analyze your current financial systems to identify pain points, redundancies and areas where manual processes are a bottleneck. This analysis will streamline your processes before you digitize them.
Convene key stakeholders. Map out new workflows and secure buy-in across the organization. Communication is fundamental, from initial brainstorming sessions to ongoing progress updates.
Create a phased process. Instead of a massive, disruptive overhaul, implement your plan in manageable iterations. Focus on intelligently automating one or two key processes first, such as accounts payable or receivable. Use these initial wins to demonstrate value and build momentum. Embed analytics as you go to measure progress and make proactive adjustments.
Scale up. Use this solid foundation in a secure cloud framework to integrate new tools, enhance data interoperability, and ensure that your system is both future-ready and protected by a zero trust architecture.
This structured approach will improve decision-making, transparency and service delivery while meeting compliance mandates as you move your organization from reactive problem-solving to a proactive and successful transformation.
There are some topics families dread broaching during the holidays. For federal employees, reductions-in-force (RIFs) and government shutdown furloughs may be added to the list of tough topics to navigate this year. If you are dreading this topic, you are not alone. Here are some options for how to navigate this conversation this year.
Talking about career change: Why family conversations matter
Whether you are experiencing a workforce reduction, transitioning between industries, or determining your next steps, your family can serve as a valuable source of emotional support and practical guidance. Open, honest communication can help your loved ones understand your motivations, fears and aspirations as you navigate this transition. Changing careers in the current environment can be especially difficult, and navigating conversations about this transition may be different than previous career transition conversations you have had with family and friends. Having this conversation in a healthy way can make a difference in your mental state during an already complex time. This conversation does not have to lead to interpersonal conflicts or distress. Consider these tips when thinking about having the conversation.
1. Prepare for the conversation and remain constructive.
Have a plan. Being prepared will help you communicate your intentions clearly and confidently when you are ready to navigate career transition conversations. Before sitting down with your family for the holidays, take some time to reflect on how you want to have conversations about career transition with your family and keep these things in mind.
Your mental state. If you are struggling with negative thoughts, consider taking those thoughts captive and reframing them. For example, if you are thinking “This time last year I was talking about getting promoted, how can I tell my family I was a part of the RIF?” Consider reevaluating that thought. Remember that being a part of a recent RIF may not be indicative of your capability, performance or value to the organization.
Your disposition. Improve your disposition by implementing or increasing healthy habits. Getting proper sleep, exercise and diet throughout the holidays can improve your mood so that you can converse more positively, have the patience to deal with challenging family members, and approach tough conversations with a clear head.
Clearing your cognitive pallet: Limit influences that sour your mood. Feed your mind uplifting information and focus on things within your actual span of control. For example, you cannot control whether the government is open or remains closed, but you can control what you do with the time that you have during this furlough. Excepted employees still working can contribute to a supportive work environment by extending grace to fellow excepted employees each day at the office.
2. Choose the right time and setting.
Have the conversation when you are in the best mental space. If you are energized and positive upon arrival at family events, consider initiating the conversation early. If you prefer to incorporate the discussion into table chat or when the family has settled after dinner, plan to have the talk then.
If you prefer not to have the conversation during the holidays, consider discussing the transition during a designated family time. A 2023 Harvard Family Study found that families who engage in weekly meetings report 50% stronger emotional bonds compared to those who do not. If your family has designated quality time, this may be a better alternative than a holiday gathering. Holidays can be stressful and emotionally charged for some family members, making it difficult to have a healthy conversation.
3. Consider your communication strategy.
Consider with which family members it makes sense to have this conversation: Having unhealthy conversations may sap your energy and negatively affect your mood, so choose wisely. Decide how you plan to respond when you are invited to share information with the family or whether you want to initiate the talk. Having conversations with supportive family members can be helpful and cathartic. You may even find more support than you anticipated when you are open and honest.
Remember that “open and honest” is not “open kimono”: Discussing a career transition with those other than your spouse does not require a detailed account of your personal and private matters. Acknowledging this as a “challenging time of transition” may be sufficient. Resist the temptation to invite family members into the intricacies of your marriage, bedroom or finances.
Consider the outcomes you want from the conversation. Jot down key points to help you stay focused during the discussion. For example, if you do not want to have the conversation repeatedly, carve out a specific time to share what you are comfortable sharing and close the conversation with something like, “That’s all I have to share about that.” As the questions come throughout the holidays, refer to when you will discuss or when you already discussed the topic. Here is an example: Uncle Bill says, “I heard you were let go, I thought you were doing well there, what happened?” Consider responding with a closed statement like, “We talked about it before dinner,” or “I plan to talk about it after dinner.”
Tailor the talk to your comfort level: You could share something like, “As some of you may know, [organization] conducted a RIF this year. My division was a part of that RIF. That is all I have to share about that.” If your family is helpful, you may want to add something like, “However, I am interested in learning about options if you have job leads or opportunities for me to continue using my skills and expertise in [career area].” Let your family know if you are seeking new challenges, personal fulfillment or better work-life balance if you feel that they can help. Honest communication can help build trust and understanding, and could even help you land your next job.
4. Listen to their concerns and neutralize criticism.
Your family may have questions or worries about finances, stability or future plans. Listen attentively and acknowledge their feelings. Let them know you value their opinions and support. This may sound something like, “I hear you. I am thinking about those things, too. I appreciate your concern and appreciate your support during this transition.” If the conversation is not constructive consider closing it with something like, “I’ve heard you,” or “We’ve heard you.”
5. Share your plan.
If your family is supportive, broadly discuss how you plan to approach your career transition. Outline steps you will take, such as updating your skills, networking, or seeking guidance from mentors. Sharing your plan demonstrates responsibility and helps alleviate uncertainty. You may share varying levels of detail with different family members based on the relationship or their ability to help.
5. Invite support and collaboration.
Ask your family for their support and input. Whether it is helping with research, offering encouragement, or brainstorming together, involving them in the process can strengthen your bond and make the transition smoother. This may need to be tailored for certain family members if family dynamics are complex.
7. Keep the conversation going.
Career transitions are ongoing journeys. Keep your family updated on your progress, celebrate small victories, and address new challenges together. Regular check-ins can help maintain open lines of communication and foster a supportive environment. If your family is incapable or unwilling to be supportive through this transition, consider keeping the conversation going with a supportive group of friends, former co-workers or faith community. Support systems are not exclusive to biological families.
Don’t go it alone
Talking with your family about a career transition is an opportunity to build a foundation of understanding and support. With preparation, empathy and honest dialogue, you can navigate this change together and set the stage for a successful new chapter.
It is important to recognize that each career journey presents its own distinct challenges and opportunities. This time of transition is significant and anomalous in many ways, so you may have trepidation about having career transition conversations. Consider seeking support and guidance from family members, friends, and current and former colleagues as you pursue new endeavors. You do not have to traverse this transition alone.
Jamel Harling is an executive coach, ombuds and advisor at Better Than Good Solutions.
The following article originally appeared on Medium and is being republished here with the author’s permission.
Don’t get me wrong, I’m up all night using these tools.
But I also sense we’re heading for an expensive hangover. The other day, a colleague told me about a new proposal to route a million documents a day through a system that identifies and removes Social Security numbers.
I joked that this was going to be a “million-dollar regular expression.”
Run the math on the “naïve” implementation with full GPT-5 and it’s eye-watering: A million messages a day at ~50K characters each works out to around 12.5 billion tokens daily, or $15,000 a day at current pricing. That’s nearly $6 million a year to check for Social Security numbers. Even if you migrate to GPT-5 Nano, you still spend about $230,000 a year.
That’s a success. You “saved” $5.77 million a year…
How about running this code for a million documents a day? How much would this cost:
import re; s = re.sub(r”\b\d{3}[- ]?\d{2}[- ]?\d{4}\b”, “[REDACTED]”, s)
A plain old EC2 instance could handle this… A single EC2 instance—something like an m1.small at 30 bucks a month—could churn through the same workload with a regex and cost you a few hundred dollars a year.
Which means that in practice, companies will be calling people like me in a year saying, “We’re burning a million dollars to do something that should cost a fraction of that—can you fix it?”
From $15,000/day to $0.96/day—I do think we’re about to see a lot of companies realize that a thinking model connected to an MCP server is way more expensive than just paying someone to write a bash script. Starting now, you’ll be able to make a career out of un-LLM-ifying applications.
The federal government’s ability to deliver results for the American people hinges on the effectiveness of its leadership. At the core of this leadership is the Senior Executive Service, a cadre of high-level officials entrusted with the responsibility of translating presidential priorities into operational outcomes. The stakes are high: Senior executive leadership affects whether the president’s agenda is properly implemented and whether agencies deliver on their missions. SES officials are the president’s senior-most career executives, and their leadership affects the lives of millions of Americans every day.
Given the gravity of their responsibilities, SES members must be equipped with the right knowledge and tools. Statutory mandates require both the Office of Personnel Management and federal agencies to provide ongoing executive development. And for good reason. Just as private-sector CEOs may benefit from executive development programs, our senior executives need the same level of preparation tailored to the constitutional role they hold and the scale of the missions they lead.
Historically, federal leadership programs have imitated academic or private-sector programs — many of which are expensive, time-consuming and not designed to meet the unique needs of government executives. With the closure of the Federal Executive Institute, OPM is refocusing and reimagining executive development, building on the best leadership development theories and practices with a renewed focus on the specific job knowledge, skills and tools SES officials need to be successful in their jobs.
Thus, to ensure the successful implementation of the president’s agenda by equipping SES through high-quality, targeted training programs, OPM has launched the Senior Executive Development Program (SEDP) — a targeted, administration-driven training initiative designed to ensure SES officials have the knowledge, context and clarity necessary to carry out the president’s agenda and best serve the American people.
The SEDP reflects a significant shift in how we approach executive development. More than just generic leadership training, the program will equip senior executives with the practical knowledge and skills to thrive as government leaders, covering topics such as constitutional governance, budget and policymaking, executive core qualifications, and strategic human capital management. Rather than relying on just generalized management theory one could get from academic or private-sector programs, this program provides high-impact, directly relevant training that speaks to the needs of today’s federal executives. The curriculum is designed around the constitutional role of the executive, the rule of law, merit system principles, and the operational realities of modern governance and leading responsive and efficient bureaucratic organizations. Participants will hear from seasoned career executive colleagues and administration officials on topics directly applicable to the complex missions and organizations they lead.
The SEDP is not a one-size-fits-all program. It’s designed to be flexible and scalable, leveraging high-quality recorded video modules delivered through OPM’s centralized learning management system. This approach allows executives to learn on demand, at their own pace, while maintaining full access to their day-to-day responsibilities. It also allows OPM to track participation and outcomes — ensuring transparency, accountability and a strong return on investment.
The goal is clear: to strengthen our federal leadership by ensuring every SES member has technical expertise and a true understanding of their constitutional responsibilities and the president’s vision. The success of any administration depends on its ability to act. And acting depends on leadership.
Through the Senior Executive Development Program, OPM is reaffirming its commitment to preparing that leadership – ensuring that America’s senior executives are ready, responsive and capable of delivering for the American people.
Scott Kupor is director of the Office of Personnel Management.
Scott Kupor, President Donald Trump's pick for director of the Office of Personnel Management, listens during Senate Homeland Security and Governmental Affairs Committee nomination hearing, April 3, 2025. (AP Photo/Mark Schiefelbein)
The following originally appears on fast.ai and is reposted here with the author’s permission.
I’ve spent decades teaching people to code, building tools that help developers work more effectively, and championing the idea that programming should be accessible to everyone. Through fast.ai, I’ve helped millions learn not just to use AI but to understand it deeply enough to build things that matter.
But lately, I’ve been deeply concerned. The AI agent revolution promises to make everyone more productive, yet what I’m seeing is something different: developers abandoning the very practices that lead to understanding, mastery, and software that lasts. When CEOs brag about their teams generating 10,000 lines of AI-written code per day, when junior engineers tell me they’re “vibe-coding” their way through problems without understanding the solutions, are we racing toward a future where no one understands how anything works, and competence craters?
I needed to talk to someone who embodies the opposite approach: someone whose code continues to run the world decades after he created it. That’s why I called Chris Lattner, cofounder and CEO of Modular AI and creator of LLVM, the Clang compiler, the Swift programming language, and the MLIR compiler infrastructure.
Chris and I chatted on Oct 5, 2025, and he kindly let me record the conversation. I’m glad I did, because it turned out to be thoughtful and inspiring. Check out the video for the full interview, or read on for my summary of what I learned.
Talking with Chris Lattner
Chris Lattner builds infrastructure that becomes invisible through ubiquity.
Twenty-five years ago, as a PhD student, he created LLVM: the most fundamental system for translating human-written code into instructions computers can execute. In 2025, LLVM sits at the foundation of most major programming languages: the Rust that powers Firefox, the Swift running on your iPhone, and even Clang, a C++ compiler created by Chris that Google and Apple now use to create their most critical software. He describes the Swift programming language he created as “Syntax sugar for LLVM”. Today it powers the entire iPhone/iPad ecosystem.
When you need something to last not just years but decades, to be flexible enough that people you’ll never meet can build things you never imagined on top of it, you build it the way Chris built LLVM, Clang, and Swift.
I first met Chris when he arrived at Google in 2017 to help them with TensorFlow. Instead of just tweaking it, he did what he always does: he rebuilt from first principles. He created MLIR (think of it as LLVM for modern hardware and AI), and then left Google to create Mojo: a programming language designed to finally give AI developers the kind of foundation that could last.
Chris architects systems that become the bedrock others build on for decades, by being a true craftsman. He cares deeply about the craft of software development.
I told Chris about my concerns, and the pressures I was feeling as both a coder and a CEO:
“Everybody else around the world is doing this, ‘AGI is around the corner. If you’re not doing everything with AI, you’re an idiot.’ And honestly, Chris, it does get to me. I question myself… I’m feeling this pressure to say, ‘Screw craftsmanship, screw caring.’ We hear VCs say, ‘My founders are telling me they’re getting out 10,000 lines of code a day.’ Are we crazy, Chris? Are we old men yelling at the clouds, being like, ‘Back in my day, we cared about craftsmanship’? Or what’s going on?”
Chris told me he shares my concerns:
“A lot of people are saying, ‘My gosh, tomorrow all programmers are going to be replaced by AGI, and therefore we might as well give up and go home. Why are we doing any of this anymore? If you’re learning how to code or taking pride in what you’re building, then you’re not doing it right.’ This is something I’m pretty concerned about…
But the question of the day is: how do you build a system that can actually last more than six months?”
He showed me that the answer to that question is timeless, and actually has very little to do with AI.
Design from First Principles
Chris’s approach has always been to ask fundamental questions. “For me, my journey has always been about trying to understand the fundamentals of what makes something work,” he told me. “And when you do that, you start to realize that a lot of the existing systems are actually not that great.”
When Chris started LLVM over Christmas break in 2000, he was asking: what does a compiler infrastructure need to be, fundamentally, to support languages that don’t exist yet? When he came into the AI world he was eager to learn the problems I saw with TensorFlow and other systems. He then zoomed into what AI infrastructure should look like from the ground up. Chris explained:
“The reason that those systems were fundamental, scalable, successful, and didn’t crumble under their own weight is because the architecture of those systems actually worked well. They were well-designed, they were scalable. The people that worked on them had an engineering culture that they rallied behind because they wanted to make them technically excellent.
In the case of LLVM, for example, it was never designed to support the Rust programming language or Julia or even Swift. But because it was designed and architected for that, you could build programming languages, Snowflake could go build a database optimizer—which is really cool—and a whole bunch of other applications of the technology came out of that architecture.”
Chris pointed out that he and I have a certain interest in common: “We like to build things, and we like to build things from the fundamentals. We like to understand them. We like to ask questions.” He has found (as have I!) that this is critical if you want your work to matter, and to last.
Of course, building things from the fundamentals doesn’t always work. But as Chris said, “if we’re going to make a mistake, let’s make a new mistake.” Doing the same thing as everyone else in the same way as everyone else isn’t likely to do work that matters.
Craftsmanship and Architecture
Chris pointed out that software engineering isn’t just about an individual churning out code: “A lot of evolving a product is not just about getting the results; it’s about the team understanding the architecture of the code.” And in fact it’s not even just about understanding, but that he’s looking for something much more than that. “For people to actually give a damn. For people to care about what they’re doing, to be proud of their work.”
I’ve seen that it’s possible for teams that care and build thoughtfully to achieve something special. I pointed out to him that “software engineering has always been about trying to get a product that gets better and better, and your ability to work on that product gets better and better. Things get easier and faster because you’re building better and better abstractions and better and better understandings in your head.”
Chris agreed. He again stressed the importance of thinking longer term:
“Fundamentally, with most kinds of software projects, the software lives for more than six months or a year. The kinds of things I work on, and the kinds of systems you like to build, are things that you continue to evolve. Look at the Linux kernel. The Linux kernel has existed for decades with tons of different people working on it. That is made possible by an architect, Linus, who is driving consistency, abstractions, and improvement in lots of different directions. That longevity is made possible by that architectural focus.”
This kind of deep work doesn’t just benefit the organization, but benefits every individual too. Chris said:
“I think the question is really about progress. It’s about you as an engineer. What are you learning? How are you getting better? How much mastery do you develop? Why is it that you’re able to solve problems that other people can’t?… The people that I see doing really well in their careers, their lives, and their development are the people that are pushing. They’re not complacent. They’re not just doing what everybody tells them to do. They’re actually asking hard questions, and they want to get better. So investing in yourself, investing in your tools and techniques, and really pushing hard so that you can understand things at a deeper level—I think that’s really what enables people to grow and achieve things that they maybe didn’t think were possible a few years before.”
This is what I tell my team too. The thing I care most about is whether they’re always improving at their ability to solve those problems.
Dogfooding
But caring deeply and thinking architecturally isn’t enough if you’re building in a vacuum.
I’m not sure it’s really possible to create great software if you’re not using it yourself, or working right next to your users. When Chris and his team were building the Swift language, they had to build it in a vacuum of Apple secrecy. He shares:
“The using your own product piece is really important. One of the big things that caused the IDE features and many other things to be a problem with Swift is that we didn’t really have a user. We were building it, but before we launched, we had one test app that was kind of ‘dogfooded’ in air quotes, but not really. We weren’t actually using it in production at all. And by the time it launched, you could tell. The tools didn’t work, it was slow to compile, crashed all the time, lots of missing features.”
His new Mojo project is taking a very different direction:
“With Mojo, we consider ourselves to be the first customer. We have hundreds of thousands of lines of Mojo code, and it’s all open source… That approach is very different. It’s a product of experience, but it’s also a product of building Mojo to solve our own problems. We’re learning from the past, taking best principles in.”
The result is evident. Already at this early stage models built on Mojo are getting state of the art results. Most of Mojo is written in Mojo. So if something isn’t working well, they are the first ones to notice.
We had a similar goal at fast.ai with our Solveit platform: we wanted to reach a point where most of our staff chose to do most of their work in Solveit, because they preferred it. (Indeed, I’m writing this article in Solveit right now!) Before we reached that point, I often had to force myself to use Solveit in order to experience first hand the shortcomings of those early versions, so that I could deeply understand the issues. Having done so, I now appreciate how smooth everything works even more!
But this kind of deep, experiential understanding is exactly what we risk losing when we delegate too much to AI.
AI, Craftsmanship, and Learning
Chris uses AI: “I think it’s a very important tool. I feel like I get a 10 to 20% improvement—some really fancy code completion and autocomplete.” But with Chris’ focus on the importance of craftsmanship and continual learning and improvement, I wondered if heavy AI (and particularly agent) use (“vibe coding”) might negatively impact organizations and individuals.
Chris: When you’re vibe-coding things, suddenly… another thing I’ve seen is that people say, ‘Okay, well maybe it’ll work.’ It’s almost like a test. You go off and say, ‘Maybe the agentic thing will go crank out some code,’ and you spend all this time waiting on it and coaching it. Then, it doesn’t work.
Jeremy: It’s like a gambling machine, right? Pull the lever again, try again, just try again.
Chris: Exactly. And again, I’m not saying the tools are useless or bad, but when you take a step back and you look at where it’s adding value and how, I think there’s a little bit too much enthusiasm of, ‘Well, when AGI happens, it’s going to solve the problem. I’m just waiting and seeing… Here’s another aspect of it: the anxiety piece. I see a lot of junior engineers coming out of school, and they’re very worried about whether they’ll be able to get a job. A lot of things are changing, and I don’t really know what’s going to happen. But to your point earlier, a lot of them say, ’Okay, well, I’m just going to vibe-code everything,’ because this is ‘productivity’ in air quotes. I think that’s also a significant problem.
Jeremy: Seems like a career killer to me.
Chris: …If you get sucked into, ‘Okay, well I need to figure out how to make this thing make me a 10x programmer,’ it may be a path that doesn’t bring you to developing at all. It may actually mean that you’re throwing away your own time, because we only have so much time to live on this earth. It can end up retarding your development and preventing you from growing and actually getting stuff done.
At its heart, Chris’s concern is that AI-heavy coding and craftsmanship just don’t appear to be compatible:
“Software craftsmanship is the thing that AI code threatens. Not because it’s impossible to use properly—again, I use it, and I feel like I’m doing it well because I care a lot about the quality of the code. But because it encourages folks to not take the craftsmanship, design, and architecture seriously. Instead, you just devolve to getting your bug queue to be shallower and making the symptoms go away. I think that’s the thing that I find concerning.”
“What you want to get to, particularly as your career evolves, is mastery. That’s how you kind of escape the thing that everybody can do and get more differentiation… The concern I have is this culture of, ‘Well, I’m not even going to try to understand what’s going on. I’m just going to spend some tokens, and maybe it’ll be great.’”
I asked if he had some specific examples where he’s seen things go awry.
“I’ve seen a senior engineer, when a bug gets reported, let the agentic loop rip, go spend some tokens, and maybe it’ll come up with a bug fix and create a PR. This PR, however, was completely wrong. It made the symptom go away, so it ‘fixed’ the bug in air quotes, but it was so wrong that if it had been merged, it would have just made the product way worse. You’re replacing one bug with a whole bunch of other bugs that are harder to understand, and a ton of code that’s just in the wrong place doing the wrong thing. That is deeply concerning. The actual concern is not this particular engineer because, fortunately, they’re a senior engineer and smart enough not to just say, ‘Okay, pass this test, merge.’ We also do code review, which is a very important thing. But the concern I have is this culture of, ‘Well, I’m not even going to try to understand what’s going on. I’m just going to spend some tokens, and maybe it’ll be great. Now I don’t have to think about it.’ This is a huge concern because a lot of evolving a product is not just about getting the results; it’s about the team understanding the architecture of the code. If you’re delegating knowledge to an AI, and you’re just reviewing the code without thinking about what you want to achieve, I think that’s very, very concerning.”
Some folks have told me they think that unit tests are a particularly good place to look at using AI more heavily. Chris urges caution, however:
“AI is really great at writing unit tests. This is one of the things that nobody likes to do. It feels super productive to say, ‘Just crank out a whole bunch of tests,’ and look, I’ve got all this code, amazing. But there’s a problem, because unit tests are their own potential tech debt. The test may not be testing the right thing, or they might be testing a detail of the thing rather than the real idea of the thing… And if you’re using mocking, now you get all these super tightly bound implementation details in your tests, which make it very difficult to change the architecture of your product as things evolve. Tests are just like the code in your main application—you should think about them. Also, lots of tests take a long time to run, and so they impact your future development velocity.”
Part of the problem, Chris noted, is that many people are using high lines of code written as a statistic to support the idea that AI is making a positive impact.
“To me, the question is not how do you get the most code. I’m not a CEO bragging about the number of lines of code written by AI; I think that’s a completely useless metric. I don’t measure progress based on the number of lines of code written. In fact, I see verbose, redundant, not well-factored code as a huge liability… The question is: how productive are people at getting stuff done and making the product better? This is what I care about.”
Underlying all of these concerns is the belief that AGI is imminent, and therefore traditional approaches to software development are obsolete. Chris has seen this movie before. “In 2017, I was at Tesla working on self-driving cars, leading the Autopilot software team. I was convinced that in 2020, autonomous cars would be everywhere and would be solved. It was this desperate race to go solve autonomy… But at the time, nobody even knew how hard that was. But what was in the air was: trillions of dollars are at stake, job replacement, transforming transportation… I think today, exactly the same thing is happening. It’s not about self-driving, although that is making progress, just a little bit less gloriously and immediately than people thought. But now it’s about programming.”
Chris thinks that, like all previous technologies, AI progress isn’t actually exponential. “I believe that progress looks like S-curves. Pre-training was a big deal. It seemed exponential, but it actually S-curved out and got flat as things went on. I think that we have a number of piled-up S-curves that are all driving forward amazing progress, but I at least have not seen that spark.”
The danger isn’t just that people might be wrong about AGI’s timeline—it’s what happens to their careers and codebases while they’re waiting. “Technology waves cause massive hype cycles, overdrama, and overselling,” Chris noted. “Whether it be object-oriented programming in the ’80s where everything’s an object, or the internet wave in the 2000s where everything has to be online otherwise you can’t buy a shirt or dog food. There’s truth to the technology, but what ends up happening is things settle out, and it’s less dramatic than initially promised. The question is, when things settle out, where do you as a programmer stand? Have you lost years of your own development because you’ve been spending it the wrong way?”
Chris is careful to clarify that he’s not anti-AI—far from it. “I am a maximalist. I want AI in all of our lives,” he told me. “However, the thing I don’t like is the people that are making decisions as though AGI or ASI were here tomorrow… Being paranoid, being anxious, being afraid of living your life and of building a better world seems like a very silly and not very pragmatic thing to do.”
Software Craftsmanship with AI
Chris sees the key as understanding the difference between using AI as a crutch versus using it as a tool that enhances your craftsmanship. He finds AI particularly valuable for exploration and learning:
“It’s amazing for learning a codebase you’re not familiar with, so it’s great for discovery. The automation features of AI are super important. Getting us out of writing boilerplate, getting us out of memorizing APIs, getting us out of looking up that thing from Stack Overflow; I think this is really profound. This is a good use. The thing that I get concerned about is if you go so far as to not care about what you’re looking up on Stack Overflow and why it works that way and not learning from it.”
One principle Chris and I share is the critical importance of tight iteration loops. For Chris, working on systems programming, this means “edit the code, compile, run it, get a test that fails, and then debug it and iterate on that loop… Running tests should take less than a minute, ideally less than 30 seconds.” He told me that when working on Mojo, one of the first priorities was “building VS Code support early because without tools that let you create quick iterations, all of your work is going to be slower, more annoying, and more wrong.”
My background is different—I am a fan of the Smalltalk, Lisp, and APL tradition where you have a live workspace and every line of code manipulates objects in that environment. When Chris and I first worked together on Swift for TensorFlow, the first thing I told him was “I’m going to need a notebook.” Within a week, he had built me complete Swift support for Jupyter. I could type something, see the result immediately, and watch my data transform step-by-step through the process. This is the Brett Victor “Inventing on Principle” style of being close to what you’re crafting.
If you want to maintain craftsmanship while using AI, you need tight iteration loops so you can see what’s happening. You need a live workspace where you (and the AI) are manipulating actual state, not just writing text files.
At fast.ai, we’ve been working to put this philosophy into practice with our Solveit platform. We discovered a key principle: the AI should be able to see exactly what the human sees, and the human should be able to see exactly what the AI sees at all times. No separate instruction files, no context windows that don’t match your actual workspace—the AI is right there with you, supporting you as you work.
This creates what I think of as “a third participant in this dialogue”—previously I had a conversation with my computer through a REPL, typing commands and seeing results. Now the AI is in that conversation too, able to see my code, my data, my outputs, and my thought process as I work through problems. When I ask “does this align with what we discussed earlier” or “have we handled this edge case,” the AI doesn’t need me to copy-paste context—it’s already there.
One of our team members, Nate, built something called ShellSage that demonstrates this beautifully. He realized that tmux already shows everything that’s happened in your shell session, so he just added a command that talks to an LLM. That’s it—about 100 lines of code. The LLM can see all your previous commands, questions, and output. By the next day, all of us were using it constantly. Another team member, Eric, built our Discord Buddy bot using this same approach—he didn’t write code in an editor and deploy it. He typed commands one at a time in a live symbol table, manipulating state directly. When it worked, he wrapped those steps into functions. No deployment, no build process—just iterative refinement of a running system.
Eric Ries has been writing his new book in Solveit and the AI can see exactly what he writes. He asks questions like “does this paragraph align with the mission we stated earlier?” or “have we discussed this case study before?” or “can you check my editor’s notes for comments on this?” The AI doesn’t need special instructions or context management—it’s in the trenches with him, watching the work unfold. (I’m writing this article in Solveit right now, for the same reasons.)
I asked Chris about how he thinks about the approach we’re taking with Solveit: “instead of bringing in a junior engineer that can just crank out code, you’re bringing in a senior expert, a senior engineer, an advisor—somebody that can actually help you make better code and teach you things.”
How Do We Do Something Meaningful?
Chris and I both see a bifurcation coming. “It feels like we’re going to have a bifurcation of skills,” I told him, “because people who use AI the wrong way are going to get worse and worse. And the people who use it to learn more and learn faster are going to outpace the speed of growth of AI capabilities because they’re human with the benefit of that… There’s going to be this group of people that have learned helplessness and this maybe smaller group of people that everybody’s like, ‘How does this person know everything? They’re so good.’”
The principles that allowed LLVM to last 25 years—architecture; understanding; craftsmanship—haven’t changed. “The question is, when things settle out, where do you as a programmer stand?” Chris asked. “Have you lost years of your own development because you’ve been spending it the wrong way? And now suddenly everybody else is much further ahead of you in terms of being able to create productive value for the world.”
His advice is clear, especially for those just starting out: “If I were coming out of school, my advice would be don’t pursue that path. Particularly if everybody is zigging, it’s time to zag. What you want to get to, particularly as your career evolves, is mastery. So you can be the senior engineer. So you can actually understand things to a depth that other people don’t. That’s how you escape the thing that everybody can do and get more differentiation.”
The hype will settle. The tools will improve. But the question Chris poses remains: “How do we actually add value to the world? How do we do something meaningful? How do we move the world forward?” For both of us, the answer involves caring deeply about our craft, understanding what we’re building, and using AI not as a replacement for thinking but as a tool to think more effectively. If the goal is to build things that last, you’re not going to be able to outsource that to AI. You’ll need to invest deeply in yourself.
Picture this: You’re a data analyst on day one at a midsize SaaS company. You’ve got the beginnings of a data warehouse—some structured, usable data and plenty of raw data you’re not quite sure what to do with yet. But that’s not the real problem. The real problem is that different teams are doing their own thing: Finance has Power BI models loaded with custom DAX and Excel connections. Sales is using Tableau connected to the central data lake. Marketing has some bespoke solution you haven’t figured out yet. If you’ve worked in data for any number of years, this scene probably feels familiar.
Then a finance director emails: Why does ARR show as $250M in my dashboard when Sales just reported $275M in their call?
No problem, you think. You’re a data analyst; this is what you do. You start digging. What you find isn’t a simple calculation error. Finance and sales are using different date dimensions, so they’re measuring different time periods. Their definitions of what counts as “revenue” don’t match. Their business unit hierarchies are built on completely different logic: one buried in a Power BI model, the other hardcoded in a Tableau calculation. You trace the problem through layers of custom notebooks, dashboard formulas, and Excel workbooks and realize that creating a single version of the truth that’s governable, stable, and maintainable isn’t going to be easy. It might not even be possible without rebuilding half the company’s data infrastructure and achieving a level of compliance from other data users that would be a full-time job in itself.
This is where the semantic layer comes in—what VentureBeat has called the “$1 trillion AI problem.” Think of it as a universal translator for your data: It’s a single place where you define what your metrics mean, how they’re calculated, and who can access them. The semantic layer is software that sits between your data sources and your analytics tools, pulling in data from wherever it lives, adding critical business context (relationships, calculations, descriptions), and serving it to any downstream tool in a consistent format. The result? Secure, performant access that enables genuinely practical self-service analytics.
Why does this matter now? As we’ll see when we return to the ARR problem, one force is driving the urgency: AI.
Legacy BI tools were never built with AI in mind, creating two critical gaps. First, all the logic and calculations scattered across your Power BI models, Tableau workbooks, and Excel spreadsheets aren’t accessible to AI tools in any meaningful way. Second, the data itself lacks the business context AI needs to use it accurately. An LLM looking at raw database tables doesn’t know that “revenue” means different things to finance and sales, or why certain records should be excluded from ARR calculations.
The semantic layer solves both problems. It makes data more trustworthy across traditional BI tools like Tableau, Power BI, and Excel while also giving AI tools the context they need to work accurately. Initial research shows near 100% accuracy across a wide range of queries when pairing a semantic layer with an LLM, compared to much lower performance when connecting AI directly to a data warehouse.
So how does this actually work? Let’s return to the ARR dilemma.
The core problem: multiple versions of the truth. Sales has one definition of ARR; finance has another. Analysts caught in the middle spend days investigating, only to end up with “it depends” as their answer. Decision making grinds to a halt because no one knows which number to trust.
This is where the semantic layer delivers its biggest value: a single source for defining and storing metrics. Think of it as the authoritative dictionary for your company’s data. ARR gets one definition, one calculation, one source of truth all stored in the semantic layer and accessible to everyone who needs it.
You might be thinking, “Can’t I do this in my data warehouse or BI tool?” Technically, yes. But here’s what makes semantic layers different: modularity and context.
Once you define ARR in the semantic layer it becomes a modular, reusable object—any tool that connects to it can use that metric: Tableau, Power BI, Excel, your new AI chatbot, whatever. The metric carries its business context with it: what it means, how it’s calculated, who can access it, and why certain records are included or excluded. You’re not rebuilding the logic in each tool; you’re referencing a single, governed definition.
This creates three immediate wins:
Single version of truth: Everyone uses the same ARR calculation, whether they’re in finance or sales or they’re pulling it into a machine learning model.
Effortless lineage: You can trace exactly where ARR is used across your organization and see its full calculation path.
Change management that actually works: When your CFO decides next quarter that ARR should exclude trial customers, you update the definition once in the semantic layer. Every dashboard, report, and AI tool that uses ARR gets the update automatically. No hunting through dozens of Tableau workbooks, Power BI models, and Python notebooks to find every hardcoded calculation.
Which brings us to the second key function of a semantic layer: interoperability.
Back to our finance director and that ARR question. With a semantic layer in place, here’s what changes. She opens Excel and pulls ARR directly from the semantic layer: $265M. The sales VP opens his Tableau dashboard, connects to the same semantic layer, and sees $265M. Your company’s new AI chatbot? Someone asks, “What’s our Q3 ARR?” and it queries the semantic layer: $265M. Same metric, same calculation, same answer, regardless of the tool.
This is what makes semantic layers transformative. They sit between your data sources and every tool that needs to consume that data. Power BI, Tableau, Excel, Python notebooks, LLMs, the semantic layer doesn’t care. You define the metric once, and every tool can access it through standard APIs or protocols. No rebuilding the logic in DAX for Power BI, then again in Tableau’s calculation language, then again in Excel formulas, then again for your AI chatbot.
Before semantic layers, interoperability meant compromise. You’d pick one tool as the “source of truth” and force everyone to use it, or you’d accept that different teams would have slightly different numbers. Neither option scales. With a semantic layer, your finance team keeps Excel, your sales team keeps Tableau, your data scientists keep Python, and your executives can ask questions in plain English to an AI assistant. They all get the same answer because they’re all pulling from the same governed definition.
Back to day one. You’re still a data analyst at that SaaS company, but this time there’s a semantic layer in place.
The finance director emails, but the question is different: “Can we update ARR to include our new business unit?”
Without a semantic layer, this request means days of work: updating Power BI models, Tableau dashboards, Excel reports, and AI integrations one by one. Coordinating with other analysts to understand their implementations. Testing everything. Hoping nothing breaks.
With a semantic layer? You log in to your semantic layer software and see the ARR definition: the calculation, the source tables, every tool using it. You update the logic once to include the new business unit. Test it. Deploy it. Every downstream tool—Power BI, Tableau, Excel, the AI chatbot—instantly reflects the change.
What used to take days now takes hours. What used to require careful coordination across teams now happens in one place. The finance director gets her answer, Sales sees the same number, and nobody’s reconciling spreadsheets at 5PM on Friday.
This is what analytics can be: consistent, flexible, and actually self-service. The semantic layer doesn’t just solve the ARR problem—it solves the fundamental challenge of turning data into trusted insights. One definition, any tool, every time.
Headlines surfaced by a simple “job market” search describe it as “a humiliation ritual” or “hell” and “an emerging crisis for entry-level workers.” The unemployment rate in the US for recent graduates is at an “unusually high” 5.8%—even Harvard Business School graduates have been taking months to find work. Inextricable from this conversation is the complication of AI’s potential to automate entry-level jobs, and as a tool for employers to evaluate applications. But the widespread availability of generative AI platforms begs an overlooked question: How are job seekers themselves using AI?
An interview study with upcoming master’s graduates at an elite UK university* sheds some light. In contrast to popular narratives about “laziness” or “shortcuts,” AI use comes from job seekers trying to strategically tackle the digitally saturated, competitive reality of today’s job market. Here are the main takeaways:
They Use AI to Play an Inevitable Numbers Game
Job seekers described feeling the need to apply to a high volume of jobs because of how rare it is to get a response amid the competition. They send out countless applications on online portals and rarely receive so much as an automated rejection email. As Franco, a 29-year-old communications student put it, particularly with “LinkedIn and job portals” saturating the market, his CV is just one “in a spreadsheet of 2,000 applicants.”
This context underlies how job seekers use AI, which allows them to spend less time on any given application by helping to cater résumés or write cover letters and thus put out more applications. Seoyeon, a 24-year-old communications student, describes how she faced repeated rejections no matter how carefully she crafted the application or how qualified she was.
[Employers] themselves are going to use AI to screen through those applications….And after a few rejections, it really frustrates you because you put in so much effort and time and passion for this one application to learn that it’s just filtered through by some AI….After that, it makes you lean towards, you know what, I’m just gonna put less effort into one application but apply for as many jobs as possible.
Seoyeon went on to say later that she even asks AI to tell her what “keywords” she should have in her application in light of AI in hiring systems.
Her reflection reveals that AI use is not a shortcut, but that it feels like a necessity to deal with the inevitable rejection and AI scanners, especially in light of companies themselves using AI to read applications—making her “passion” feel like a waste.
AI as a Savior to Emotional Labor
The labor of applying to jobs and dealing with constant rejection and little human interaction makes it a deeply emotional process that students describe as “draining” and “torturing,” which illuminates that AI is a way to reduce not just the time of labor but the emotional aspect of it.
Franco felt that having to portray himself as “passionate” for hundreds of jobs that he would not even hear back from was an “emotional toll” that AI helped him manage.
Repeating this process to a hundred job applications, a hundred job positions and having to rewrite a cover letter in a way that sounds like if it was your dream, well I don’t know if you can have a hundred dreams.…I would say that it does have an emotional toll….I think that AI actually helps a lot in terms of, okay, I’m going to help you do this cover letter so you don’t have to mentally feel you’re not going to get the shot.
Using AI thus acted as a buffer for the emotional difficulties of being a job seeker, allowing students to conserve mental energy in a grueling process while still applying to many jobs.
The More Passionate They Are, the Less AI They Use
AI use was not uniform by any means, even though the job application process often requires the same materials. Job seekers had “passion parameters” in place, where they dial down their use for a job that they were more passionate about.
Joseph, a 24-year-old psychology student, put this “human involvement” as “definitely more than 50%” for a role he truly desires, whereas for a less interesting role, it’s about “20%–30%.” He differentiates this by describing how, when passion is involved, he does deep research into the company as opposed to relying on AI’s “summarized, nuanced-lacking information,” and writes the cover letter from scratch—only using AI to be critical of it. In contrast, for less desirable jobs, AI plays a much more generative role in creating the initial draft that he then edits.
This points to the fact that while AI feels important for labor efficiency, students do not use it indiscriminately, especially when passion is involved and they want to put their best foot forward.
They Understand AI’s Flaws (and Work Around Them)
In their own words, students are not heedlessly “copying and pasting” AI-generated materials. They are critical of AI tools and navigate them with their concerns in mind.
Common flaws in AI-generated material include sounding “robotic” and “machine-like,” with some “AI” sounding words including “explore” and “delve into.” Joseph asserted that he can easily tell which one is written by a human, because AI-generated text lacks the “passion and zeal” of someone who is genuinely hungry for the job.
Nandita, a 23-year-old psychology student, shared how AI’s tendency to “put you on a pedestal” came through in misrepresenting facts. When she asked AI to tailor her résumé, it embellished her experience of “a week-long observation in a psychology clinic” into “community service,” which she strongly felt it wasn’t—she surmised this happened because community service was mentioned in the job description she fed AI, and she caught it and corrected it.
Consequently, using AI in the job hunt is not a passive endeavor but requires vigilance and a critical understanding to ensure its flaws do not hurt you as a job seeker.
They Grapple with AI’s Larger Implications
Using AI is not an unconditional endorsement of the technology; all the students were cognizant of (and worried about) its wider social implications.
John, a 24-year-old data science student, drew a distinction between using AI in impersonal processes versus human experiences. While he would use it for “a cover letter” for a job he suspects will be screened by AI anyway, he worries how it will be used in other parts of life.
I think it’s filling in parts of people’s lives that they don’t realize are very fundamental to who they are as humans. One example I’ve always thought of is, if you need it for things like cover letters, [that]s OK] just because it’s something where it’s not very personal.…But if you can’t write a birthday card without using ChatGPT, that’s a problem.
Nandita voiced a similar critique, drawing on her psychology background; while she could see AI helping tasks like “admin work,” she worries about how it would be used for therapy. She argues that an AI therapist would be “100% a Western…thing” and would fail to connect with someone “from the rural area in India.”
The understanding of AI shows that graduates differentiate using it for impersonal processes, like job searching in the digital age, from more human-to-human situations where it poses a threat.
Some Grads Are Opting Out of AI Use
Though most people interviewed were using AI, some rejected it entirely. They voiced similar qualms that AI users had, including sounding “robotic” and not “human.” Julia, a 23-year-old law student, specifically mentioned that her field requires “language and persuasiveness,” with “a human tone” that AI cannot replicate, and that not using it would “set you apart” in job applications.
Mark, a 24-year-old sociology student, acknowledged the same concerns as AI users about a saturated online arms race, but instead of using AI to send out as many applications as possible, had a different strategy in mind: “talking to people in real life.” He described how he once secured a research job through a connection in the smoking area of a pub.
Importantly, these job seekers had similar challenges with the job market as AI users, but they opted for different strategies to handle it that emphasize human connection and voice.
Conclusion
For graduate job seekers, AI use is a layered strategy that is a direct response to the difficulties of the job market. It is not about cutting corners but carefully adapting to current circumstances that require new forms of digital literacy.
Moving away from dialogue framing job seekers as lazy or unable to write their own materials forces us to look at how the system itself can be improved for applicants and companies alike. If employers don’t want AI use, how can they create a process that makes room for human authenticity as opposed to AI-generated materials that sustain the broken cycle of hiring?
Artificial intelligence has quickly become a centerpiece of cybersecurity strategy across government and industry. Agencies are under pressure to modernize, and AI promises to accelerate response times, automate enforcement, and increase efficiency at scale.
But there is a critical risk that’s not getting enough attention. Automation without visibility doesn’t eliminate complexity. It multiplies it. And for federal agencies operating under stringent mandates and oversight, that creates a dangerous blind spot.
When AI turns enforcement into chaos
Consider an organization that turned to AI to manage firewall rules. The idea was simple: Allow the AI to continuously generate and enforce rules, so that the network remained secure in real time. On paper, it worked. The AI delivered consistent enforcement and even a solid return on investment.
But when auditors stepped in, they discovered a problem. Instead of consolidating rules, the AI had simply layered them on repeatedly. What had been a 2,000-line ruleset grew into more than 20,000 lines. Buried within were contradictions, redundancies and overlaps.
For operators, the network functioned. But for compliance officers, it was a nightmare. Demonstrating segmentation of sensitive environments, something federal mandates and Payment Card Industry Data Security Standards both require, meant combing through 20,000 rules line by line. AI had streamlined enforcement, but it had rendered oversight almost impossible.
This is the irony of AI in cybersecurity: It can solve problems while simultaneously creating new ones.
Masking complexity, not removing it
Federal IT leaders know that compliance is not optional. Agencies must not only enforce controls, but also prove to Congress, regulators and oversight bodies that controls are effective. AI-generated logic, while fast, often can’t be explained in human terms.
That creates risk. Analysts may be right that AI is enabling “preemptive” security, but it’s also masking the misconfigurations, insecure protocols and segmentation gaps that adversaries exploit. Worse, AI may multiply those issues at a scale human operators can’t easily trace.
In short, if you can’t see what AI is changing, you can’t secure it.
Federal mandates demand proof, not promises
Unlike private enterprises, federal agencies face multiple layers of oversight. From Federal Information Security Modernization Act audits to National Institute of Standards and Technology framework requirements, agencies must continuously demonstrate compliance. Regulators won’t accept “trust the AI” as justification. They want evidence.
That’s where AI-driven enforcement creates the most risk: It undermines explainability. An agency may appear compliant operationally but struggle to generate transparent reports to satisfy audits or demonstrate adherence to NIST 800-53, Cybersecurity Maturity Model Certificaiton or zero trust principles.
In an environment where operational uptime is mission-critical, whether for Defense communications, transportation systems or civilian services, losing visibility into how security controls function is not just a compliance risk. It’s a national security risk.
Independent oversight is essential
The solution is not to reject AI. AI can and should play a vital role in federal cybersecurity modernization. But it must be paired with independent auditing tools that provide oversight, interpretation and clarity.
Independent auditing serves the same purpose in cybersecurity as it does in finance: verifying the work. AI may generate and enforce rules, but independent systems must verify, streamline and explain them. That dual approach ensures agencies can maintain both speed and transparency.
I’ve seen agencies and contractors struggle with this first-hand. AI-driven automation delivers efficiency, but when auditors arrive, they need answers that only independent visibility tools can provide. Questions like:
Is the cardholder or mission-critical data environment fully segmented?
Are insecure protocols still running on public-facing infrastructure?
Can we produce an auditable trail proving compliance with NIST or PCI requirements?
Without these answers, federal agencies risk compliance failures and, worse, operational disruption.
The federal balancing act
Federal leaders also face a unique challenge: balancing security with mission-critical operations. In defense, for example, communication downtime in the field is catastrophic. In civilian agencies, outages in public-facing systems can disrupt services for millions of citizens.
This creates tension between network operations centers (focused on uptime) and security operations centers (focused on compliance). AI promises to keep systems running, but without visibility, it risks tipping the balance too far toward operations at the expense of oversight.
The federal mission demands both: uninterrupted operations and provable security. AI can help achieve that balance, but only if independent oversight ensures explainability.
Questions federal security leaders must ask
Before integrating AI further into their cybersecurity posture, federal leaders should ask:
What visibility do we have into AI-generated changes? If you can’t explain the logic, you can’t defend it.
How will we validate compliance against federal frameworks? Oversight bodies won’t accept black-box answers.
What happens when AI introduces errors? Automation multiplies mistakes as quickly as it enforces controls.
Do we have independent tools for oversight? Without them, auditors, regulators and mission leaders will be left in the dark.
Don’t trade clarity for convenience
AI is transforming federal cybersecurity. But speed without clarity is a liability. Agencies cannot afford to trade explainability for convenience.
The warning is clear: AI is quietly building operational debt while masking misconfigurations. Without independent oversight, that debt will come due in the form of compliance failures, operational disruption or even breaches.
Federal leaders should embrace AI’s benefits, but not at the cost of visibility. Because in cybersecurity, especially in government, if you can’t see what AI is changing, you can’t secure it.
Ian Robinson is the chief product officer for Titania.
As the federal government contends with tightening budgets, lean staffing and soaring citizen expectations, it faces a unique opportunity — and obligation — to modernize service delivery by investing in shared services. The notion of centralized provisioning might conjure up all sorts of challenges and issues; however, it is a proven avenue to lower costs, eliminate duplication and elevate service performance. While shared services isn’t the answer for all functions, we possess valuable learned lessons and survey feedback on shared services to create a powerful pathway to increase government effectiveness while lowering costs.
The federal government has demonstrated tangible benefits of shared services related to administrative systems. For example, between fiscal 2002 and 2015, consolidating payroll and HR systems generated more than $1 billion in cost savings and an additional $1 billion when 22 payroll systems were consolidated into four, according to the Government Accountability Office. A 2024 report published by the Federation of American Scientists noted that consolidating the payroll centers yielded cumulative savings exceeding $3.2 billion. Other measurable results include the General Services Administration’s fleet management program that consolidated more than 5,000 agency-owned vehicles on leasing, maintenance and administrative costs. Shared IT services have also expanded steadily, with the adoption of Login.gov, USAJOBS, and data center consolidation that saved over $2.8 billion, according to GAO and the Office of Management and Budget in 2020.
Why it matters — and why now
The federal government continues to advance priorities that improve citizen services while driving down costs as we enter the artificial intelligence era where AI, data and information are transforming industries, big data and human capabilities. Agencies are facing a pressing need to modernize IT systems, increase efficiencies by incorporating automation and AI, and increase cybersecurity. Without integrated business services, agencies will struggle to maintain infrastructure, secure their systems and modernize for the AI era. Consolidated IT investments, such as Login.gov and ID.me, have proven to provide stronger, more resilient platforms that enhance cybersecurity and protect mission-critical systems, provide standardized data and analytics and improve transparency.
Still, shared services must be implemented with care. Agencies need flexibility to select providers that best fit their mission-specific requirements. Focusing first on areas where agencies are already seeking solutions — such as accounting, fleet management and office space aligned by security requirements — offers a pragmatic path forward. Service providers must be held to strict performance standards, with service-level agreements ensuring that quality improves alongside efficiency. Equally important, strong leadership and coordination are necessary to sustain momentum.
Agencies like the Office of Personnel Management, GSA and Treasury, which have successfully acted as managing partners in the past, can provide the oversight and accountability required for long-term success. Rather than measuring Quality Service Management Offices (QSMOs) solely by their early momentum, their success should be understood in light of the current environment: smaller budgets, fewer staff and an increased focus on mission delivery. In this context, the adoption of integrated business services positions agencies for long-term gains.
Shared services provide the architecture for a more modern, efficient and mission-focused government. From payroll to fleet management to IT modernization, the federal government has demonstrated the value of this approach through billions of dollars in savings and significant performance improvements. With bipartisan policy support, proven blueprints and advances in shared platforms, the federal enterprise is well-positioned to expand shared services — carefully, collaboratively and with agency choice at its core. If pursued deliberately, shared services can become a cornerstone of fiscal responsibility and high-quality service delivery for the American people.
Erika Dinnie is the vice president of federal strategy and planning for MetTel. Before joining the company, Dinnie served as the General Services Administration’s associate chief information officer for digital infrastructure technologies for nearly 10 years, overseeing GSA’s IT infrastructure, systems, software and applications.
The following originally appeared on Asimov’s Addendum and is being republished here with the author’s permission.
The other day, I was looking for parking information at Dulles International Airport, and was delighted with the conciseness and accuracy of Google’s AI overview. It was much more convenient than being told that the information could be found at the flydulles.com website, visiting it, perhaps landing on the wrong page, and finding the information I needed after a few clicks. It’s also a win from the provider side. Dulles isn’t trying to monetize its website (except to the extent that it helps people choose to fly from there.) The website is purely an information utility, and if AI makes it easier for people to find the right information, everyone is happy.
An AI overview of an answer found by consulting or training on Wikipedia is more problematic. The AI answer may lack some of the nuance and neutrality Wikipedia strives for. And while Wikipedia does make the information free for all, it depends on visitors not only for donations but also for the engagement that might lead people to become Wikipedia contributors or editors. The same may be true of other information utilities like GitHub and YouTube. Individual creators are incentivized to provide useful content by the traffic that YouTube directs to them and monetizes on their behalf.
And of course, an AI answer provided by illicitly crawling content that’s behind a subscription paywall is the source of a great deal of contention, even lawsuits. So content runs a gamut from “no problem crawling” to “do not crawl.”
There are a lot of efforts to stop unwanted crawling, including Really Simple Licensing (RSL) and Cloudflare’s Pay Per Crawl. But we need a more systemic solution. Both of these approaches put the burden of expressing intent onto the creator of the content. It’s as if every school had to put up its own traffic signs saying “School Zone: Speed Limit 15 mph.” Even making “Do Not Crawl” the default puts a burden on content providers, since they must now affirmatively figure out what content to exclude from the default in order to be visible to AI.
Why aren’t we putting more of the burden on AI companies instead of putting all of it on the content providers? What if we asked companies deploying crawlers to observe common sense distinctions such as those that I suggested above? Most drivers know not to tear through city streets at highway speeds even without speed signs. Alert drivers take care around children even without warning signs. There are some norms that are self-enforcing. Drive at high speed down the wrong side of the road and you will soon discover why it’s best to observe the national norm. But most norms aren’t that way. They work when there’s consensus and social pressure, which we don’t yet have in AI. And only when that doesn’t work do we rely on the safety net of laws and their enforcement.
As Larry Lessig pointed out at the beginning of the Internet era, starting with his book Code and Other Laws of Cyberspace, governance is the result of four forces: law, norms, markets, and architecture (which can refer either to physical or technical constraints).
So much of the thinking about the problems of AI seems to start with laws and regulations. What if instead, we started with an inquiry about what norms should be established? Rather than asking ourselves what should be legal, what if we asked ourselves what should be normal? What architecture would support those norms? And how might they enable a market, with laws and regulations mostly needed to restrain bad actors, rather than preemptively limiting those who are trying to do the right thing?
I think often of a quote from the Chinese philosopher Lao Tzu, who said something like:
Losing the way of life, men rely on goodness. Losing goodness, they rely on laws.
I like to think that “the way of life” is not just a metaphor for a state of spiritual alignment, but rather, an alignment with what works. I first thought about this back in the late ’90s as part of my open source advocacy. The Free Software Foundation started with a moral argument, which it tried to encode into a strong license (a kind of law) that mandated the availability of source code. Meanwhile, other projects like BSD and the X Window System relied on goodness, using a much weaker license that asked only for recognition of those who created the original code. But “the way of life” for open source was in its architecture.
Both Unix (the progenitor of Linux) and the World Wide Web have what I call an architecture of participation. They were made up of small pieces loosely joined by a communications protocol that allowed anyone to bring something to the table as long as they followed a few simple rules. Systems that were open source by license but had a monolithic architecture tended to fail despite their license and the availability of source code. Those with the right cooperative architecture (like Unix) flourished even under AT&T’s proprietary license, as long as it was loosely enforced. The right architecture enables a market with low barriers to entry, which also means low barriers to innovation, with flourishing widely distributed.
Architectures based on communication protocols tend to go hand in hand with self-enforcing norms, like driving on the same side of the street. The system literally doesn’t work unless you follow the rules. A protocol embodies both a set of self-enforcing norms and “code” as a kind of law.
What about markets? In a lot of ways, what we mean by “free markets” is not that they are free of government intervention. It is that they are free of the economic rents that accrue to some parties because of outsized market power, position, or entitlements bestowed on them by unfair laws and regulations. This is not only a more efficient market, but one that lowers the barriers for new entrants, typically making more room not only for widespread participation and shared prosperity but also for innovation.
Markets don’t exist in a vacuum. They are mediated by institutions. And when institutions change, markets change.
Consider the history of the early web. Free and open source web browsers, web servers, and a standardized protocol made it possible for anyone to build a website. There was a period of rapid experimentation, which led to the development of a number of successful business models: free content subsidized by advertising, subscription services, and ecommerce.
Nonetheless, the success of the open architecture of the web eventually led to a system of attention gatekeepers, notably Google, Amazon, and Meta. Each of them rose to prominence because it solved for what Herbert Simon called the scarcity of attention. Information had become so abundant that it defied manual curation. Instead, powerful, proprietary algorithmic systems were needed to match users with the answers, news, entertainment, products, applications, and services they seek. In short, the great internet gatekeepers each developed a proprietary algorithmic invisible hand to manage an information market. These companies became the institutions through which the market operates.
They initially succeeded because they followed “the way of life.” Consider Google. Its success began with insights about what made an authoritative site, understanding that every link to a site was a kind of vote, and that links from sites that were themselves authoritative should count more than others. Over time, the company found more and more factors that helped it to refine results so that those that appeared highest in the search results were in fact what their users thought were the best. Not only that, the people at Google thought hard about how to make advertising that worked as a complement to organic search, popularizing “pay per click” rather than “pay per view” advertising and refining its ad auction technology such that advertisers only paid for results, and users were more likely to see ads that they were actually interested in. This was a virtuous circle that made everyone—users, information providers, and Google itself—better off. In short, enabling an architecture of participation and a robust market is in everyone’s interest.
Amazon too enabled both sides of the market, creating value not only for its customers but for its suppliers. Jeff Bezos explicitly described the company strategy as the development of a flywheel: helping customers find the best products at the lowest price draws more customers, more customers draw more suppliers and more products, and that in turn draws in more customers.
Both Google and Amazon made the markets they participated in more efficient. Over time, though, they “enshittified” their services for their own benefit. That is, rather than continuing to make solving the problem of efficiently allocating the user’s scarce attention their primary goal, they began to manipulate user attention for their own benefit. Rather than giving users what they wanted, they looked to increase engagement, or showed results that were more profitable for them even though they might be worse for the user. For example, Google took control over more and more of the ad exchange technology and began to direct the most profitable advertising to its own sites and services, which increasingly competed with the web sites that it originally had helped users to find. Amazon supplanted the primacy of its organic search results with advertising, vastly increasing its own profits while the added cost of advertising gave suppliers the choice of reducing their own profits or increasing their prices. Our research in the Algorithmic Rents project at UCL found that Amazon’s top advertising recommendations are not only ranked far lower by its organic search algorithm, which looks for the best match to the user query, but are also significantly more expensive.
As I described in “Rising Tide Rents and Robber Baron Rents,” this process of replacing what is best for the user with what is best for the company is driven by the need to keep profits rising when the market for a company’s once-novel services stops growing and starts to flatten out. In economist Joseph Schumpeter’s theory, innovators can earn outsized profits as long as their innovations keep them ahead of the competition, but eventually these “Schumpeterian rents” get competed away through the diffusion of knowledge. In practice, though, if innovators get big enough, they can use their power and position to profit from more traditional extractive rents. Unfortunately, while this may deliver short term results, it ends up weakening not only the company but the market it controls, opening the door to new competitors at the same time as it breaks the virtuous circle in which not just attention but revenue and profits flow through the market as a whole.
Unfortunately, in many ways, because of its insatiable demand for capital and the lack of a viable business model to fuel its scaling, the AI industry has gone in hot pursuit of extractive economic rents right from the outset. Seeking unfettered access to content, unrestrained by laws or norms, model developers have ridden roughshod over the rights of content creators, training not only on freely available content but ignoring good faith signals like subscription paywalls, robots.txt and “do not crawl.” During inference, they exploit loopholes such as the fact that a paywall that comes up for users on a human timeframe briefly leaves content exposed long enough for bots to retrieve it. As a result, the market they have enabled is of third party black or gray market crawlers giving them plausible deniability as to the sources of their training or inference data, rather than the far more sustainable market that would come from discovering “the way of life” that would balance the incentives of human creators and AI derivatives.
Here are some broad-brush norms that AI companies could follow, if they understand the need to support and create a participatory content economy.
For any query, use the intelligence of your AI to judge whether the information being sought is likely to come from a single canonical source, or from multiple competing sources. For example, for my query about parking at Dulles Airport, it’s pretty likely that flydulles.com is a canonical source. Note however, that there may be alternative providers, such as additional off-airport parking, and if so, include them in the list of sources to consult.
Check for a subscription paywall, licensing technologies like RSL, “do not crawl” or other indication in robots.txt, and if any of these things exists, respect it.
Ask yourself if you are substituting for a unique source of information. If so, responses should be context-dependent. For example, for long form articles, provide basic info but make clear there’s more depth at the source. For quick facts (hours of operation, basic specs), provide the answer directly with attribution. The principle is that the AI’s response shouldn’t substitute for experiences where engagement is part of the value. This is an area that really does call for nuance, though. For example, there is a lot of low quality how-to information online that buries useful answers in unnecessary material just to provide additional surface area for advertising, or provides poor answers based on pay-for-placement. An AI summary can short-circuit that cruft. Much as Google’s early search breakthroughs required winnowing the wheat from the chaff, AI overviews can bring a search engine such as Google back to being as useful as it was in 2010, pre-enshittification.
If the site has high quality data that you want to train on or use for inference, pay the provider, not a black market scraper. If you can’t come to mutually agreed-on terms, don’t take it. This should be a fair market exchange, not a colonialist resource grab. AI companies pay for power and the latest chips without looking for black market alternatives. Why is it so hard to understand the need to pay fairly for content, which is an equally critical input?
Check whether the site is an aggregator of some kind. This can be inferred from the number of pages. A typical informational site such as a corporate or government website whose purpose is to provide public information about its products or services will have a much smaller footprint than an aggregator such as Wikipedia, Github, TripAdvisor, Goodreads, YouTube, or a social network. There are probably lots of other signals an AI could be trained to use. Recognize that competing directly with an aggregator with content scraped from that platform is unfair competition. Either come to a license agreement with the platform, or compete fairly without using their content to do so.If it is a community-driven platform such as Wikipedia or Stack Overflow, recognize that your AI answers might reduce contribution incentives, so in addition, support the contribution ecosystem. Provide revenue sharing, fund contribution programs, and provide prominent links that might convert some users into contributors. Make it easy to “see the discussion” or “view edit history” for queries where that context matters.
As a concrete example, let’s imagine how an AI might treat content from Wikipedia:
Direct factual query (”When did the Battle of Hastings occur?”): 1066. No link needed, because this is common knowledge available from many sites.
More complex query for which Wikipedia is the primary source (“What led up to the Battle of Hastings?) “According to Wikipedia, the Battle of Hastings was caused by a succession crisis after the death of King Edward the Confessor in January 1066, who died without a clear heir. [Link]”
Complex/contested topic: “Wikipedia’s article on [X] covers [key points]. Given the complexity and ongoing debate, you may want to read the full article and its sources: [link]”
For rapidly evolving topics: Note Wikipedia’s last update and link for current information.
Similar principles would apply to other aggregators. GitHub code snippets should link back to repositories, YouTube queries should direct to videos, not just summarize them.
These examples are not market-tested, but they do suggest directions that could be explored if AI companies took the same pains to build a sustainable economy that they do to reduce bias and hallucination in their models. What if we had a sustainable business model benchmark that AI companies competed on just as they do on other measures of quality?
Finding a business model that compensates the creators of content is not just a moral imperative, it’s a business imperative. Economies flourish better through exchange than extraction. AI has not yet found true product-market fit. That doesn’t just require users to love your product (and yes, people do love AI chat.) It requires the development of business models that create a rising tide for everyone.
Many advocate for regulation; we advocate for self-regulation. This starts with an understanding by the leading AI platforms that their job is not just to delight their users but to enable a market. They have to remember that they are not just building products, but institutions that will enable new markets and that they themselves are in the best position to establish the norms that will create flourishing AI markets. So far, they have treated the suppliers of the raw materials of their intelligence as a resource to be exploited rather than cultivated. The search for sustainable win-win business models should be as urgent to them as the search for the next breakthrough in AI performance.
Cyber adversaries aren’t standing still, and our defenses can’t either. In an environment where government networks face relentless, increasingly sophisticated attacks, it’s evident that perimeter-based security models belong in the past. A zero trust framework redefines the approach: Every user, device, and connection is treated as unverified until proven otherwise, or “trust but verify.” By assuming breach, zero trust delivers what today’s government missions demand: speed, resilience and the ability to contain damage before it spreads.
To truly operationalize zero trust, agencies must look beyond theory and embrace emerging technologies. Many federal organizations are already turning to artificial intelligence and digital twins to get there. A digital twin — a software-based replica of a real-world network — creates an invaluable proving ground. Rather than waiting for an adversary to strike live systems, agencies can safely simulate cyberattacks, test and refine policies, and validate updates before deployment. In my view, this marks a fundamental shift: Digital twins aren’t just a tool, they represent the future of proactive cyber defense, where learning, adaptation and resilience happen before a crisis, not after.
This approach doesn’t just strengthen agency defenses; it also streamlines operations. Instead of maintaining expensive, outdated physical labs, agencies can rely on digital twins to keep pace with evolving cyber threats. Most recently, a large government agency demonstrated the power of this approach by overcoming years of technical debt, rapidly reconfiguring critical systems, and building a testing environment that delivered greater speed, precision and efficiency that advanced their mission and operational goals.
Strategies for anticipating compromise while ensuring operational resilience
Digital twins offer significant potential for enhancing cybersecurity, yet their widespread adoption remains nascent due to several challenges, including budget constraints and agency inertia. Agencies can reference established frameworks such as the National Institute of Standards and Technology SP 800-207 and the Cybersecurity Infrastructure and Security Agency Zero Trust Maturity Model, to guide their zero trust journeys. However, with various legacy systems, cloud services and devices, agencies require zero trust capabilities for their specific needs. The core challenge for government then becomes how to proactively implement effective zero trust strategies that anticipate compromises while ensuring continued operations.
To address these challenges and effectively implement zero trust, here are key actions for agency leaders to consider that include people, process and tools:
People
Embrace change management
Zero trust implementation is as much about people and process as it is about technology. To foster cross-team buy-in, agencies must clearly articulate the “why” behind zero trust. Instead of just a technical mandate, zero trust should be framed as a strategy to improve security and efficiency. This involves creating a shared understanding of the framework’s benefits and how it impacts each team member.
Quantify and communicate value
Measuring the ROI of zero trust is complex, as preventing incidents yields invisible benefits. How will you define success: reduced risk, faster compliance, operational consistency? Agencies should set milestones for measuring security posture improvements and regulatory progress while recognizing the limitations of conventional ROI calculations.
Process
Adopt zero trust as a damage-limitation strategy
Rather than asking, “How do we stop every breach?” agencies should take steps to shift from prevention-only thinking to dynamic containment and defense, such as:
Developing an incident response plan that outlines roles, responsibilities and communication protocols for cyberattack stages.
Conducting regular tabletop exercises and simulations to test the plan’s effectiveness and find improvement areas.
Automating security workflows to accelerate response times and reduce human error.
Be thorough with zero trust planning
According to public sector best practices, projects with 90% planning and 10% execution are far more likely to succeed. Agency technology and information leaders should take an active role in driving zero trust transformation, ensuring comprehensive planning, stakeholder engagement, and organizational buy-in are prioritized from the outset.
Tools
Leverage digital twins
Agencies are turning to emerging technology, including AI and digital twins, to keep pace with threat actors. Government IT and SecOps teams can deploy digital twins to simulate attacks, validate controls and reduce costly physical testing environments. Digital twins should also be considered a safe space for agencies to experiment, identify vulnerabilities, and optimize policies before deployment — an invaluable asset for agencies navigating mixed legacy and cloud ecosystems. Moreover, model-based systems engineering and agile approaches, paired with digital twins, can empower agencies to “rehearse” security incidents and fine-tune architectures.
Tackle tool sprawl using informed consolidation
The sheer volume of disparate vendors and tools can undermine even the best zero trust architecture. Utilizing digital twins to map and simulate your IT environment allows for thoughtful consolidation without sacrificing security or compliance. Lastly, agencies should identify where they are duplicating capabilities and envision a streamlined, mission-focused toolset.
Accelerating zero trust at scale
To address the pace and complexity of future threats, government agencies must act boldly by embracing zero trust not only as a framework but also as a fundamental mindset for continual adaptation and resilience.
By harnessing the power of technologies like AI and digital twins, modernizing planning and response strategies, and committing to cross-team collaboration, agencies can outmaneuver adversaries and protect their most critical missions.
The path forward is clear: Operational resilience is achieved by investing today in future-ready strategies that anticipate compromise, ensure continuity and empower every stakeholder to play a proactive role in defense.
John Fair is vice president of Air Force sales and account management at Akima.
Login
