In this short discussion, Justin and Billy explore who should be responsible for keeping the agents.md file up‑to‑date within a design system. Justin explains that when a design system serves multiple product teams, the design system team should provide an easy, frictionless way for each product team to add their own design‑system context to agents.md, but the product teams remain the primary owners of the file. For a design system that supports only a single product, the responsibility still leans toward the product team because agents.md is largely a product‑specific artifact, with the design system team contributing only a subset. The conversation also raises questions about validation, automation, and ongoing maintenance, emphasizing that the ownership model should adapt to the scope and structure of the organization.
Justin has one.
Agents.md sits at the top of the pyramid as context. Once a team there, who's responsible for keeping that file accurate as the system evolves? Is that a person's ongoing job? Does it get validated, generated automatically?
On the engineering side, we try to build, and we do, the design system in a way that empowers product teams, that they can work the way they want to work. And so this is somewhat of a how-to-work question. And so if your design system is serving multiple product teams, we would provide those product teams with an easy way to add design system context to their agents.md file. But that's where we would stop and we would say, here's a quick way to do this. But if you have a different way to do this, if you manage your agents.md in a way that's somehow unique, but fits your team. It's really your choice to make as to how you do that, but we want to give them as much of a frictionless way to adopt design system context as we can. Now, if your design system is serving maybe a single product, it's just a smaller scope maybe than what I was describing just now, then it's more of a discussion, right? Who owns that? I would still say that it's the product team and less of the design system team. Only because the design system team is a portion of that agent's MD. It's not the primary piece of the agent's MD. It's still just a subset of the whole. And so the whole would be the product team who, who need to use the design system, not the design system being the primary umbrella under which the product team works, if, if you will. Would you agree with that, Billy?
Yeah, I would agree with that. And a lot of the stuff that even that we, we deliver out for, for teams, like for example, just to go back to like our Design MD libraries and, and, or Markdown files and, and things that we put out there. We try to keep the same contribution model that we do for, for components. And if folks have something that they feel needs to go in there, or they made a local version that pulled down and made some adjustments and edits, we, we really want teams to push that back to us because we can't be everywhere. Catching everything all the time. And sometimes we'll put something in there that, that worked well for us, but then somebody will find a way to enhance it and it just works 10 times better. And so we want to make sure that we have that as well.
