[{"data":1,"prerenderedAt":18},["ShallowReactive",2],{"post-paved-paths-in-the-agent-era":3},{"slug":4,"title":5,"excerpt":6,"content":7,"tags":8,"readingTime":15,"publishedAt":16,"published":17},"paved-paths-in-the-agent-era","Paved paths, or: who builds the road when everyone can ship","The agent era drops the cost of building for every team. It does not drop the cost of paving. The argument here is for the role the agent era is going to make most under-priced: the person who abstracts across business domains and lays the paths everyone else walks on — the paved paths, the unified auth, the security guardrails, the infrastructure modules. Without that role, the unbundling produces a fleet of Frankenstein products.","\n## The observation\n\nIn the last year, I have started to see a new shape of failure mode at companies that have crossed the agent-era threshold. It is not the failure mode I named in [[when-everyone-can-ship|the agent-era piece]] — the version where the call to build is made by people who do not have the professional background to make the call. This one is more subtle. The call to build is now being made by people who are perfectly capable of building. The thing they are not capable of is building *the same way* the next person is going to build.\n\nThe result is a fleet of internal products that all work, and none of which know each other exist. I have been calling this the Frankenstein problem in my head — not because the products are bad, but because the products are stitched together from pieces that have no idea what the other pieces are doing. Each piece has its own auth, its own data model, its own opinion about what a user even is. Each piece is a competent piece. The whole is a monster.\n\nI watched this happen at the company I currently work at, in a quieter way than the failure mode I named earlier. The HR director's systems, in some cases, were not built by vendors. They were built, on the side, by people on different teams, with different stacks, in different weeks. The systems, taken on their own terms, work. The systems, taken together, do not. The data does not move between them. The user has to log in three times. The analytics, when you finally get them, do not agree with each other. The maintenance, when the person who built the thing leaves, falls to nobody.\n\nI think this is the version of the unbundling I did not name in the first piece. The first piece was about *whether* to build. This piece is about *how* to build, when the answer is yes.\n\n## What I am trying\n\nI am trying to argue for a specific role in a company that has crossed the threshold of \"everyone can ship.\" The role is not the developer. The role is not the architect in the old sense — the person who reviews the design and signs off on the merge. The role is something closer to what platform engineering has been trying to name for the last decade, but sharpened for the agent era.\n\nThe role, in my reading, is the person who builds the road. Not the person who drives. Not the person who reviews the driving. The person who lays the asphalt, pours the curb, paints the line, installs the sign, and keeps the road in a state where the next person — and the next — can drive on it without thinking about it.\n\nThe paved paths show up in the work I have actually done. The GUILD Certificate Intelligence Ecosystem is a paved path: any new certificate, from any lab, in any brand, gets the same QR template, the same verification page, the same cross-brand conversion path. The person building a new certificate does not decide whether to add a QR code, what the QR should link to, or what the page should say. The path is laid. The person fills in the variables.\n\nThe GUILD Bio Link Surface is a paved path: any new campaign, on any of the social accounts, gets the same config slot, the same analytics, the same attribution. The person launching the campaign does not decide whether to add UTM parameters, where to put the post in the grid, or how to wire the click to the backend. The path is laid. The person edits the config.\n\nThe GUILD Digital Operations Ecosystem is a paved path: any new post, on any account, in any market, gets the same fields, the same workflow, the same review, the same analytics. The planner does not decide what columns the spreadsheet has. The system decided. The planner fills in the cells.\n\nThe principle, in my reading, is the same principle each time. The system decides the boring decisions. The person decides the interesting ones. The agent era, paradoxically, makes the boring decisions more important, not less — because the boring decisions are the ones that have to be the same across a hundred teams, and the hundred teams, in the agent era, are now a hundred teams that can ship a hundred different things.\n\n## The principle, in one sentence\n\n> The job of the platform engineer in the agent era is to make the right thing the path of least resistance, and the wrong thing the path of most resistance — and to do it without the people walking the path noticing the path is there.\n\nI have been holding this principle for about a year, and I am still working out how to make it operational in a way that scales. The hard part is not the principle. The hard part is the disagreement about what the right thing is. The path is local. A platform engineer in HR is going to lay a different path than a platform engineer in engineering. A company that sells to enterprise is going to lay a different path than one that sells to consumers. The principle is shared. The path is not.\n\n## What this looks like, in practice\n\nWhen I think about the paved paths I have built, the parts that survive are the parts that did three things at once.\n\nThe path is *opinionated*. It is not a buffet. It is not \"here are seventeen ways you could build this thing.\" It is \"this is the way we build this thing, and if you want to do it differently, you have to bring a good reason and you have to live with the consequences.\" The opinionated-ness is what makes the path a path, instead of a menu.\n\nThe path is *invisible* to the person walking it. The person does not think about auth. The person does not think about the data model. The person does not think about the deployment. The person thinks about the thing they are trying to do, and the path takes care of the rest. Don Norman's argument about good design being invisible — the door handle you do not think about, the kitchen tap you do not think about — applies here in the same way. The path is the door handle. The path is the tap. The path is invisible.\n\nThe path is *shared* across teams, not held by one. The path is a thing in the org chart. The path has an owner. The path has a roadmap. The path has a budget. The path has a community of practice, even if the community is just three people in three time zones. The path, in the moment it becomes a critical part of the system, cannot be the side project of one person. The path is the system.\n\nI have not always been good at laying paths that meet all three of those tests. The GUILD Digital Operations Ecosystem, in the version I left it in, was strong on opinionated and visible-to-the-walker. It was weak on shared. The roadmap was held by one person, and the moment that person left, the roadmap was held by nobody, and the path started to drift. I am less sure than I was a year ago about how to fix that part. I am fairly sure it is the part that has to be fixed.\n\n## What I am not saying\n\nI am not saying every company needs a platform engineer. A company of fifteen people does not need a platform engineer. A company of fifteen people needs a single person who knows all the systems, because the systems are small enough to be known. A platform engineer is for the company that has crossed the threshold of \"no single person knows all the systems\" — and the threshold, in the agent era, is probably earlier than most teams think.\n\nI am not saying paved paths kill the bottom-up culture. The bottom-up culture is, in my reading, the part of the agent era that is most worth protecting. The platform engineer is not there to stop people from building. The platform engineer is there to make the building cheaper for the things that are obviously the right things, and more expensive for the things that are obviously the wrong things. The bottom-up culture is what makes the path worth laying in the first place. A path that nobody walks is just concrete.\n\nI am not saying the paved path is a finished idea. I am chewing on it. I think the principle is right. I am less sure about the operationalization. I have not found the meeting where the platform engineer and the team on the ground agree on what the right thing is, in a way that does not turn into a fight about who is the parent and who is the child. I am still working out how to structure that conversation.\n\n## Where this connects\n\n[[when-everyone-can-ship|The agent-era piece]] is the precondition. The agent era drops the cost of building. The architect becomes the bottleneck. The architect cannot keep up. The agent era does not need fewer architects. The agent era needs architects who are doing a different job.\n\n[[why-dirty-work-deserves-serious-consideration|The dirty-work piece]] is the closest cousin. The argument there was that dirty work belongs to the system, creative work belongs to the person. The argument here is the same argument, applied one level up. The platform engineer builds the system that takes the dirty work off the team's plate — auth, security, deployment, monitoring, the things the team should not have to think about. The team keeps the creative work. The team keeps the call.\n\n[[one-link-is-a-bottleneck|The bio-link piece]] is the same insight at a smaller surface. The bio link is the highest-intent moment. The link in the bio deserved a surface that knew about the backend, not a third-party tool. The paved path is the same move at company scale. The next team that needs to ship a thing deserves a path that knows about the company's systems, not a blank editor and a \"good luck.\"\n\nThe GUILD systems are the worked examples. The Certificate Intelligence Ecosystem, the Bio Link Surface, the Digital Operations Ecosystem — each of them is a paved path. Each of them is the principle in the world, in production, paying the rent. The work is in the seams.\n\n## What the literature already says\n\nI did not invent the concept of paved paths. The framing is borrowed, openly, from platform engineering — a discipline that has been thinking about this exact problem for the last decade, in the context of cloud adoption, microservice adoption, and the move to internal developer platforms. The term \"paved road\" or \"paved path\" goes back at least as far as the work at Amazon on internal tooling, and it has been re-articulated by ThoughtWorks, by the engineering team at Spotify, and by the platform engineering community that has organized itself around the question of what the next decade of internal tooling is going to look like.\n\nThe agent era, in my reading, is going to make the platform engineering question sharper, not softer. The cost of building is dropping for every team. The number of teams building is rising. The number of paved paths the company has, in proportion, is not rising. The gap, in my reading, is the same gap. The agent era has just made it visible to a much larger group of people.\n\nI am less sure that the platform engineering community has the answer for the agent era specifically. The community has been thinking about developer experience. The agent era is thinking about user experience for agents, which is a different problem in a few important ways. I am still chewing on the difference. I think the difference is the part I will be writing about in a year, if I am still writing.\n\n## A postscript\n\nI want to say one more thing, even though I am not sure it is the right thing to say.\n\nThe agent era, in the worst version of itself, is going to produce a generation of internal products that look like a city built by a hundred different contractors, none of whom have ever met each other, each of whom was given the same plot of land and the same brief and the same deadline. The city is going to have fifty front doors. The city is going to have fifty back doors. The city is going to have, in the worst case, fifty different shapes of key. The city is going to be, in a way that no single person can fix, broken.\n\nThe paved path is, in my reading, the part of the answer that the agent era is not going to give you for free. The cost of building is dropping. The cost of paving is not. The cost of paving is, if anything, rising — because the surface area of what needs to be paved is rising, and the people who can lay the path are the people who can see across the city, and the people who can see across the city are the people who are not in the weeds of the next sprint.\n\nI am going to keep writing about this. The principle, in my reading, is the part of the agent era that is going to be most under-priced, most under-hired, and most under-funded. The principle is also, in my reading, the part that is going to determine whether the agent era is a net positive for the company that has decided to take it seriously.\n\nThe hardest part is not building the path. The hardest part is convincing the company that the path is worth building, before the city has been built.\n    ",[9,10,11,12,13,14],"AI Agents","Architecture","Process","Org Design","Team Design","Note to self",8,"2026-08-08",true,1786166905485]