OpenAI has signed a 10-year lease for an enormous Ohio data center that will eventually provide 8 gigawatts of computing capacity and require at least 10 gigawatts of new power generation. According to OpenAI, Nvidia will be supplying the chips and guaranteeing up to $105 billion in lease and power obligations. From the report: The facility -- which will be built and owned by SoftBank's SB Energy -- illustrates the immensity of the computing and power needed to fuel the growth of the AI economy. The data center will have 8 IT-gigawatts of computing capacity, powered by 10 gigawatts of new energy generation, on private land and federal property formerly used for uranium enrichment.
Nvidia -- which will be the exclusive provider of chips to the site -- agreed to guarantee up to $105 billion in conditional lease and power payment obligations to SB Energy, according to an SEC filing (PDF). The so-called "land, power and shell" deal structure could allow for multiple upgrade cycles for new generations of Nvidia infrastructure at the site, Nvidia CEO Jensen Huang said on X.
A massive 9.2 gigawatts of new gas-fired power is ultimately envisioned for the Ohio project, which U.S. officials say Japan is funding under the 2025 trade and investment deal. SB Energy and SoftBank "will build at least 10 GW of new energy generation," a joint announcement from Nvidia, OpenAI and SB Energy states. Nvidia also said today that it's investing $1.5 billion in SB Energy to back its "continued evolution into a leading AI infrastructure developer."
GitHub was hit by a widespread outage Monday. (GitHub Logo / GeekWire Illustration)
GitHub, the Microsoft-owned code-sharing platform with 225 million users, was down for more than three hours Monday morning, disrupting software development work around the world.
The issue started at 6:40 a.m. Pacific. Within an hour and a half, nearly every part of the service was broken or slowed, including the GitHub website, tools for reviewing and merging code, the automated systems that test and ship software, and the GitHub Copilot AI coding assistant.
GitHub said on its status page that it found the source of the problem shortly after 9:30 a.m. and by 10 a.m. had the outage under control, with services recovering. Copilot remained listed as an active incident and GitHub said it was still monitoring things overall for stability.
As of publication time, the company hadn’t detailed the cause of the issue.
GitHub has been struggling for many months with the surge of AI-driven coding. GitHub CTO Vladimir Fedorov wrote in April that the company set out last fall to expand its capacity tenfold, then concluded by February that it needed to build for 30 times its current scale.
In June, a Microsoft spokesperson told Business Insider that the spike in AI agent development had tested GitHub’s infrastructure limits, and said the company was accelerating GitHub’s move onto Azure while pursuing a multi-cloud strategy. BI reported that the strategy includes renting capacity from Amazon Web Services, Microsoft’s biggest cloud rival.
When I was in college, I joined the beta for one of the first versions of AI inline completions in VS Code. It felt like a game changer. Since then, GenAI has fundamentally changed software development: hybrid teams where agents and humans work in tandem, with the developer at the center as visionary and orchestrator. We are living in that transition right now.
As a natural byproduct of how fast innovation in GenAI has moved, we now have tools to help us plan, build, review, and ship code. But in the current state, many workflows still feel disjointed. Context gets lost across threads and surfaces, and too much time gets spent reviewing agent-generated work. Agents can produce changes faster than any human can review them, and most developer tools were not originally designed for multi-agent orchestration. It becomes easy to lose track of what ran, what changed, what was validated, and what still needs human judgment.
The GitHub Copilot app is a major step toward addressing this. One feature in particular that I’ve learned to love and use almost every day is canvases. Canvases let developers and agents interact on a durable, shared surface. Instead of treating chat as the only place where work happens, canvases make work visible, steerable, and approvable as it unfolds.
Chat is great for intent, but weak for durable execution
I still believe chat is one of the best interfaces we have for intent. It’s where you can think, refine, and direct. It’s fast and flexible, especially when the problem is still ambiguous.
But once an agent starts doing real work, chat becomes a long scroll of instructions, logs, pivots, and corrections. The important parts are technically there, but buried: the plan, decision points, validations, and approval moments. If you have to reconstruct all of that from history, you’re already paying a coordination tax.
Canvases solve that by giving workflows a home. They make state explicit and persistent. Humans can inspect and guide. Agents can update and progress. Both can stay aligned without constantly replaying context.
The first build: Java Modernization Studio
One of the first canvases I built was Java Modernization Studio. Java modernization is exactly the kind of workflow where visibility and governance matter: assessment, planning, migration tasks, validation gates, and readiness to ship.
In a chat-only experience, those steps blur together. You can still move forward, but it gets harder to audit and harder to trust at scale, especially with multiple contributors. Teams keep asking the same expensive questions: What stage are we in? What decisions were made? What is blocked? What still needs human approval?
The studio made each phase explicit and inspectable. Instead of parsing narrative history, teams could see operational state directly. Instead of guessing what happened, they could verify it. Human reviewers could focus on high-signal judgments while agents kept execution moving between checkpoints.
After that, I built Site Studio for a very different workflow: creating and managing personal site content. It’s content-heavy rather than migration-heavy, but the orchestration challenge is similar: section progress, iterative edits, review loops, and status transitions.
In a chat-only flow, content can drift quickly. A section gets revised, then revised again, and confidence drops in what is current. Feedback gets scattered, drafts repeat, and momentum slows because each iteration starts by rebuilding context.
Site Studio keeps that state durable. Section status is visible. Draft values are persisted as work happens. Human review points are explicit. The agent can keep moving while the human can steer, approve, or redirect without losing the thread.
Across both canvases, I found the same repeatable blueprint:
Define workflow states clearly.
Surface the decisions that matter.
Persist progress and drafts immediately.
Keep explicit human approval points.
This shifts the model from prompt-by-prompt interaction to durable collaborative workflows. You stop treating each turn like a fresh start and start treating each workflow like a system with memory, structure, and control.
Cost and efficiency: yes, canvases are an investment
I also want to be explicit about cost: canvases can be an investment. For instance, Site Studio cost me about 2,000 AI credits, and the modernization canvas cost me about 3,000 AI credits. They take effort to design and shape well.
But in the long run, especially for repeated workflows, that investment pays back. Durable surfaces reduce repeated prompting, reduce context loss, reduce unnecessary back-and-forth, and reduce rework. Over time, that can save both time and money while improving trust and throughput.
So for me, this is not “spend more tokens for nicer UX.” It’s “invest in better workflow architecture so recurring work becomes more efficient, predictable, and governable.”
Available now in awesome-copilot
The canvases I built—Java Modernization Studio and Site Studio—are available in awesome-copilot for anyone who wants to use them, adapt them, or learn from them.
If you are already using Copilot agents, a practical next step is to pick one repeated workflow and build a minimal canvas around it with /create-canvas. Start small, run real work, and iterate from actual usage. If it helps your team, contribute it back to awesome-copilot so others can benefit too.
We’re still early in this transition, but the direction is clear. Agents can accelerate execution. Humans provide vision, judgment, and accountability. Canvases are one way to make that partnership real, durable, and scalable.
The following article originally appeared on Mediumand is being republished here with the author’s permission.
Everybody’s talking about the death of developers. I get it. The developer whose job was to write boilerplate or scaffold CRUD apps is done—a model can do that in seconds, and that developer is not coming back. But the people announcing the end of programming are missing something. There’s a new job title that’s starting to emerge across several areas in software.
Architects and developers are becoming orchestrators—one person directing work that once required entire teams. This shift will reach far beyond software, but software engineering is where I’ve seen it firsthand.
The orchestrator stands between the machine and the consequences. (Image Assist by Anthropic)
An orchestrator knows how to develop software, but their job isn’t to write the code anymore—it’s to oversee a system, orchestrate tools and agents, and generate components into something that has to work in production. But the most important distinction between an “orchestrator” and a “software developer” is that an orchestrator focuses less on delivering software and more on orchestrating the systems that can both operate and develop software.
The technical expertise that used to be applied to figuring out the structure of a database schema or an object model will now be applied to guiding a set of subsystems that have taken responsibility for most tactical, line-level decisions. Where a “developer” in 2023 focused on deciding how a React application might store state, an “orchestrator” in 2027 is focused on a DESIGN.md file that sets standards for a subsystem that is responsible for fusing analytics data with input from customer feedback to recommend, test, and implement site changes as part of a large, more autonomous approach to running a business.
Orchestrating systems of delegated intelligence
While everyone is calling everything “agents” these days, I’m also going to put forward an idea. An orchestrator can and will use systems that resemble some of the more “agentic” approaches we’re all using today, from systems like Hermes, OpenClaw, or every other system that has started to call itself an “agent.” I’m starting to see that the term is overused. Taking a step back from the technology we’re using today, I’m going to suggest that the job of an “orchestrator” is to coordinate systems that fall under a new category called “delegated intelligence.”
We’ve been calling everything “artificial intelligence” for several decades. That term, mixed with “Generative AI” and “Inference Engines,” fails to capture what we’re starting to see in practice. An agentic system that has memory and can start to operate with a level of independence is exhibiting “delegated intelligence,” and the word “delegated” is doing a lot of work. It implies that systems in this category will always be traceable back to an accountable operator, or, in this case, an Orchestrator.
Fundamental to the shift toward Orchestrators is a combination of automation, productivity, and accountability. As organizations, companies, and governments start to make use of delegated intelligence to support a more autonomous approach to design, operation, and engineering, there will be an increasing need to establish accountability. If your business operates critical infrastructure on a set of autonomous agents, one of the questions that will become necessary to answer in the case of an outage is “on whose authority was this delegated intelligence operating?”
An ecosystem of orchestrators: Generalists and specialists
There are orchestrators, and then there are technical specialists. A move towards generalist expertise marks orchestrators, because the capability of a specialist is now found mostly in a model. You’ll still need a couple of specialists, but not one for every technology—and even some of those specialists will be specialist orchestrators. It’s going to get complicated.
You’ll be looking for generalist orchestrators who understand the whole thing end to end. You could think of an orchestrator as an expert Renaissance programmer—usually people with a couple of decades of experience who understand the end-to-end life cycle of software development. Those are the individuals becoming orchestrators, and it’s changing the whole makeup of IT departments. We’re no longer programmers.
. . .
Let me use my own experience here to capture what the new reality looks like. I recently had to add DRM to a series of audiobooks I’m self-publishing—an inaudible watermark encoding order-specific data into the audio file, so that if I find one of these files in the wild, I can identify who bought it. I’m not a subject matter expert in overlaying audio watermarks, but I do understand how to write code that processes sound files.
Orchestration: From months to minutes
This particular task would have taken me weeks or months, and not long ago I would have started the project by creating a git repository and opening up an IDE. That’s not how it works in 2026.
When I orchestrated the creation of this system two weeks ago, it took 20 minutes, and the tools gave me three dimensions of highly encrypted watermarking and fingerprinting—essentially the work product of 3 steganographic audio specialists.
Okay, I lied—it was 40 minutes. The first 20 minutes I was asking the models to come up with 5 different approaches so I could choose the right one. But I want to emphasize that I asked the system to produce 5 different proposals and then model the long-term cost and operability of each option. I also gave it direction to think about customer experience, create a matrix of pros and cons for each option, and end with a recommendation.
This was all done by a system that has been tracking content development for several months, and it used customer knowledge, analytics, and product design to inform the set of options it was giving its Orchestrator before jumping into implementation.
Your job isn’t code, it’s orchestration
Part of my job now is to leverage these tools not just to create, but during ideation, product design, and quality engineering. The Orchestrator is there because that person knows what questions to ask. It would have taken me three months and a large team to get this done only four years ago, and I shipped it without reading every line.
To be frank, it’s a weird space to be in, and the “me” from three years ago would have been really uncomfortable hearing that I implemented something but didn’t write the code myself. In fact, my initial reaction to Steve Yegge saying that he should stop reading his code was very negative, and I still have some reservations about that belief, but I will say that in my own practice, I’m starting to not read my code—because it’s not my code.
Like a lot of programmers reading this, I’ve had to go through an identity moment as a programmer—becoming comfortable with shipping something to production I might not have read every line of. There’s maybe a hundred thousand lines of code—too much to read—and honestly, it’s not my job anymore. I’m an orchestrator, and it would be highly inefficient if I tried to keep up.
I’m not a vibe-coder, and I’m not a “citizen developer”—a term I hate enough to curse at because it’s just the wrong word. I’m someone who could write the code, but I’ve decided to delegate that task to a system that has more information at hand than I could ever hope to assemble. And while these systems, the delegated intelligence tools like an agent, can implement systems in mere minutes, they still need a human to weigh in on direction. And I would argue that we still need a human to remain present and accountable.
The Orchestrator knows enough to understand what was done for them and how to dig into the details when something breaks. They know how to debug, they have a sense of what’s valid and what’s not, and they’re honest about what they know and what they don’t.
Orchestrators as finishers
Here’s the controversial part. This is absolutely not about “democratizing access to technology.” There’s a myth that anyone can pick up these tools and code, and that is true—yes, anyone can code, but not everyone can deliver it to production in a scalable and secure manner.
A colleague of mine recently wrote that it’s easy to start projects with generative AI, but what’s difficult is finishing them. It takes the same effort, energy, and technical expertise to deliver something to production as it always has.
The idea that anyone and their brother can pick up a generative AI tool and create technical perfection—that myth is about to expire. If you build a complicated, technical system without an individual responsible for orchestrating the creation and operation of that system, there will come a day when you have to pay someone to do that for you, and that someone is going to charge you a lot.
Orchestrators plan for contingencies: Ability to support
That DRM system I just talked about—I haven’t read every line, but before I shipped it, I made sure that I understood the baseline for support going forward. While I delegated authority to an agent to create it, I also made sure to ask that same agent to capture code locations, architecture, approach, and to generate a system of documents that could be used to debug and support it if AI was unavailable.
Have I read this “pilot manual” from start to finish before deploying this to production? No. But I understand where the throttle gauge is, and if I needed to land this plane without autopilot, I could. This is one of the responsibilities of the new role. Planning for “offline,” thinking through contingencies.
The key point is that I’m qualified enough to understand the pilot manual that AI wrote for me in case I need to debug it, and if AI were to disappear tomorrow, I could rebuild it myself. That is not true for many people introducing themselves to coding through AI, and it creates a dependence on the tools that needs to be managed—one of the ways it will be managed is through certified orchestrators who can create but also support systems without the tools, especially in regulated and critical areas.
Adapting the organization to the emerging role
Things are changing fast—one Orchestrator equals 20 or 30 developers, plus teams of QA engineers. While we’re still going to need product people and people who think about the customer, the technical work is consolidating around the person directing it.
And before you ask—why not just call this an architect? Because architect never worked. If you’ve worked in a company that has architects, you’ll understand that while a few architects continue to keep up-to-date with technology, many also tend to lean back on past experience delegating day-to-day technology to junior engineers. This role differs from that of an architect because it calls for someone to be engaged with specifications, outcomes, and operations.
Orchestrator isn’t the incommunicative programmer that stares at an IDE all day; they are the individual that understands the full, end-to-end flow not just of data in a technical system but how the business operates and adapts autonomously. They are technical, but they are also focused on providing oversight, and they are the individual responsible for deciding what intelligence can be delegated.
So how do we create orchestrators? Not from a bootcamp or a six-week certificate. This is going to take an apprentice program—years of it, the same way we create doctors and lawyers. You work under someone who knows what to pay attention to, and you learn by watching them make decisions.
These are employees who can do real damage, and they’re a walking liability. When a corporation buys insurance for people writing code, that’s one set of risks. When you’re insuring professionals who are a hundred times more productive, they also carry a hundred times more responsibility. Insurance rates, regulations, and certification requirements are all going to go up. Doctors carry malpractice insurance because their decisions affect people’s lives.
A Professional Engineer has to be licensed because engineering affects public safety. Orchestrators are headed the same direction.
If you fast-forward 20 or 30 years, what we call programmers now are going to be orchestrators, and they’re going to look more like doctors and lawyers than like this band of people we have now who write code.
Code will be part of the job, but not the majority of it.
Democracy’s Library: Tools for Participation Wednesday, October 21, 2026 Internet Archive, San Francisco REGISTER: In person | Virtual
Democracy invites participation; democracies require it.
At the Internet Archive, we believe libraries can help make that participation possible by preserving knowledge and providing the tools to explore and build upon it. This year, our annual celebration, “Democracy’s Library: Tools for Participation,” will showcase the many ways people can participate through the Internet Archive—from saving and contributing materials to exploring government records, researching history, and building new tools with our collections and APIs.
We’ll celebrate the Wayback Machine and the many other Internet Archive tools that help people preserve, explore, share, and build knowledge together.
We’ll also spotlight partners and creators who are building on top of the Internet Archive’s data and infrastructure, demonstrating how shared library resources can become a foundation for discovery and collaboration. In person and via livestream, we’ll explore what happens when a library doesn’t just preserve knowledge, but gives people the tools to use it, build with it, and participate in creating what comes next.
Celebrate with us!
Our annual celebration is a hybrid event, with an in-person street party at Internet Archive headquarters in San Francisco and a livestream for those joining from afar.
In person: Wednesday, October 21, at 300 Funston Avenue, San Francisco. REGISTER NOW
Virtual: Join the livestream from wherever you are. REGISTER NOW
Go behind the scenes at the Physical Archive
Doors Open: Go Behind the Scenes at the Physical Archive Tuesday, October 20, 2026 Physical Archive, Richmond, California REGISTER: In person
The celebration begins the night before with a special opportunity to peek behind the doors of the Physical Archive in Richmond, California.
Join us on Tuesday, October 20, from 6–8 p.m. for a behind-the-scenes tour of the physical collections of books, music, film, and video.
This special insider event offers a look at the lifecycle of physical materials—from donation and preservation to digitization and access. We’ll also have samples from generous donations and acquisitions of books, records, microfiche, and more on display.
Every team building AI agents eventually hits the same wall. The demo works. The agent calls the right tool, gets a reasonable answer, and everyone in the room nods. Then someone tries to run it against real systems with real data, and it falls apart in ways that have nothing to do with the model.
It can’t find the right API among a dozen similarly named internal services. It calls an endpoint that changed six months ago because nobody updated the reference it was trained on. It has a credential with more access than the task needed, sitting in a config file where anyone, or anything, could read it. Nobody can tell you what it did last Tuesday or what it’s costing you this month.
None of that is a model problem. It’s an infrastructure problem, and it’s the same one every generation of production software has had to solve: how do you give a new class of consumer safe, reliable, observable access to your systems? We solved this for human developers over two decades of API tooling. Now agents are the ones making the calls, and the infrastructure underneath them has to catch up.
I’ve had some version of this conversation dozens of times with customers, and heard it echoed by hundreds of developers at our Agents & APIs meetups. Once you strip away the specifics of each team’s stack, the same pattern shows up underneath: four fundamentals, each solving a distinct failure mode that shows up once agents, not humans, are driving your API traffic.
Fundamental 1: A system of record agents can reason over
Before an agent can call an API well, it has to know the API exists, know which version is canonical, and know who’s responsible for it. Most organizations don’t have a clean answer to that. They have a Confluence page from two years ago, a Slack thread where someone finally figured out which of the seventeen payment APIs is the real one, and tribal knowledge that leaves with whoever holds it.
Humans route around this kind of mess through experience and asking around. Agents can’t. If your API surface isn’t captured somewhere structured, an agent either can’t find what it needs or, worse, confidently uses the wrong thing.
This is what Postman calls context debt, and it’s why the platform’s foundation is a Context Graph: a continuously updated map of every API, service, contract, and dependency across an organization. It’s not documentation in the sense of a page someone wrote once. It’s a live index that can answer “which payment API is canonical, who owns it, and what breaks if I change it” the same way every time, whether the thing asking is a person or a model.
Postman exposes this context two ways. Postman Agent Mode works alongside developers inside the workspace in real time, drafting tests, filling out collections, and flagging contract issues as they’re written. The AI Engineer is the more autonomous piece: a sandboxed agent that explores undocumented APIs, runs design reviews, and checks pull requests for contract regressions, with write access gated behind human approval rather than granted outright. Postman’s own writeup on the AI Engineer is worth reading if you want the deeper mechanics.
The part that matters beyond Postman’s own workspace is the Postman MCP Server, which exposes the API Catalog and Context Graph through the Model Context Protocol. That means an agent running in Claude Code, Cursor, or any other MCP-compatible tool can pull real organizational context instead of guessing at it from training data. The source code is on GitHub if you want to see how it’s wired up. This is the layer everything else depends on: without a real system of record, the other three fundamentals have nothing accurate to work from.
Fundamental 2: APIs that are actually discoverable by machines
Assume the context problem is solved and an agent has found the API it needs. Next problem: can it actually call it correctly on the first try?
Most API documentation is written for people. Prose descriptions, example payloads, schemas that are typed loosely enough for a human to fill in the gaps by inference. That works fine when a developer is reading a portal and applying judgment. It’s structurally opaque to a model, which ends up in a loop of inference and trial and error: guessing at auth headers, hallucinating parameters that don’t exist, retrying against a schema it never actually understood.
At human-scale request volume, that’s an annoyance. At agent scale, where a single workflow might make hundreds of calls in a session, it’s a reliability problem that compounds. This is the gap Fern is built to close, by re-indexing API surfaces into typed, machine-readable formats and strongly typed SDKs that a model can parse directly instead of inferring from prose.
The reasoning here tracks with what’s showing up in the broader ecosystem. MCP itself exists because tool definitions need to be structured and discoverable rather than described in free text for a model to use them reliably. The pattern holds at every layer: the more your API surface reads like data instead of prose, the fewer wrong guesses an agent makes before it succeeds.
Fundamental 3: Access control built for delegated, dynamic identities
Traditional API gateways and credential management assume human-shaped traffic: a known client, a predictable access pattern, a credential scoped once at deploy time and rarely touched again. Agentic systems break all three assumptions at once. A single orchestrated workflow can fan out across dozens of internal services under a delegated identity, with a scope that got decided at prompt time, not deploy time. An agent that spawns sub-agents needs each of them to inherit a narrower slice of access, not a copy of its own.
The data backs up how badly this is already going. GitGuardian’s 2026 State of Secrets Sprawl report found AI-assisted commits leaking hardcoded secrets at more than double the rate of human-only commits. Industry coverage of agentic identity and access management is converging on the same conclusion: the gateway has to evolve from a traffic router into an identity enforcement point. It needs to verify delegation claims and apply policy before a request runs, not after.
Postman’s answer splits into two pieces that work together. Fabric Gateway is the control plane, deployed inside your own cloud, that routes and governs traffic across models, MCP servers, agents, and internal APIs, enforcing policy and circuit-breaking consistently so individual services don’t each have to build their own agent-aware auth logic. Postman Passport is the credential layer underneath it, and it takes a genuinely different approach to the secret-sprawl problem than most credential managers. Instead of distributing real API keys to whatever is asking for them, it issues credential references: tokens bound to a specific identity that are useless without a matching private key. The actual API keys stay inside your VPC and get resolved at a Secure Access Proxy, never touching the agent’s reasoning layer or showing up in a log. If a credential reference leaks, there’s no underlying secret for anyone to exploit.
That’s a meaningfully different security posture than rotating leaked keys after the fact. It’s proactive instead of reactive, which matters a lot more once the thing holding your credentials is a model that can be prompted, tricked, or makes a mistake at 3 a.m. with nobody watching.
Fundamental 4: Operations for a workforce that includes agents
Say the first three fundamentals are handled. Your agents can find the right APIs, call them correctly, and only touch what they’re scoped to touch. You still don’t know how many agents are actually running, which ones are worth the compute they’re burning, or whether the one your sales team built six months ago quietly stopped working three weeks ago.
This is the gap most teams don’t notice until it’s expensive. Agents get built, shipped, and then forgotten, because nobody owns the equivalent of an on-call rotation for them. There’s no shared registry, so the same agent gets rebuilt by three different teams who didn’t know the others had already solved the problem.
Astro is Postman’s answer to that operational gap, and its framing is deliberately less about governance and more about “agents become teammates”: one place to deploy agents, track how they perform, see what they cost, and decide where to invest more. A shared agent registry and reusable blueprints mean a PR review agent built by one team doesn’t have to be rebuilt from scratch by the next. Built-in tracing means agents get tuned against how they actually behave in production instead of a benchmark score, and cost visibility broken down by agent, model, and team turns “should we scale this” into a data question instead of a guess.
Where Fabric Gateway answers “is this specific request authorized right now,” Astro answers “which agents are running, how are they doing, and are they actually making the team better.” Audit trails and guardrails live here too, but they’re in service of that broader operational question rather than being the whole point.
How the four fundamentals fit together
Fundamental
The failure mode without it
What it needs to provide
System of record
Agents can’t find or trust the right API
A live, queryable map of APIs, owners, and dependencies
Discoverability
Agents guess at parameters and hallucinate calls
Typed, machine-readable schemas and SDKs
Access control
Broad, static credentials leak or overreach
Scoped, short-lived, delegation-aware access
Operations
Agents run unmonitored, uncosted, and unowned
Registry, tracing, and cost visibility across teams
These aren’t four separate tools you bolt on in whatever order is convenient. They compose in sequence. The system of record gives the discoverability layer something accurate to index. The access control layer decides what an agent can actually reach once it’s found and called the right API. And none of it means anything operationally unless you can see which agents are running, what they’re doing, and whether they’re worth what they cost.
Skip the first fundamental and the other three are built on sand: perfectly typed, perfectly scoped, perfectly observable calls to the wrong API. Skip the third and you’ve built a fast, well-documented way to leak credentials at scale. The order matters because each layer assumes the one below it is solid.
Where I’d start
If you’re building agents today and none of this exists yet, don’t try to solve all four at once. Start with the system of record. It’s the least glamorous of the four and the easiest to skip, which is exactly why most teams skip it, and it’s also the one everything else silently depends on. An agent with perfect credential scoping and full observability that’s still calling the wrong API is still broken, just in a well-monitored way.
After that, access control is the one I’d prioritize over discoverability or operations, mainly because the cost of getting it wrong is asymmetric. A confusing API surface makes agents slower and less reliable. A leaked credential can be a genuine incident.
Getting familiar with the Model Context Protocol is a reasonable place to start regardless of which platform you land on, since it’s an open standard rather than something proprietary to any one vendor. Whatever you use to fill in these four fundamentals, the underlying question is the same one Postman poses: it’s no longer really about whether your APIs are ready for AI. It’s whether your AI is ready for production.
Log in
