# Agent, skill, or MCP? Which to use and when to use them | AWS’ Clare Liguori | Dev Interrupted Powered by LinearB

> AWS Senior Principal Engineer Clare Liguori joins the show to untangle modern agentic architecture and help engineering teams choose between full agents, reusable skills, and stateless MCP servers. Discover how the simplified MCP 7.28 spec reduces architectural bloat and enables enterprise AI to scale without heavy maintenance overhead.

_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._


```json
{
  "@context": "https://schema.org",
  "@type": "PodcastEpisode",
  "name": "Agent, skill, or MCP? Which to use and when to use them | AWS’ Clare Liguori",
  "description": "AWS Senior Principal Engineer Clare Liguori joins the show to untangle modern agentic architecture and help engineering teams choose between full agents, reusable skills, and stateless MCP servers. Discover how the simplified MCP 7.28 spec reduces architectural bloat and enables enterprise AI to scale without heavy maintenance overhead.",
  "url": "https://linearb.io/dev-interrupted/podcast/aws-clare-liguori-agent-skill-mcp-architecture",
  "datePublished": "2026-08-18T12:00:00.000Z",
  "partOfSeries": {
    "@type": "PodcastSeries",
    "name": "Dev Interrupted",
    "url": "https://linearb.io/dev-interrupted/podcasts"
  },
  "actor": {
    "@type": "Person",
    "name": "Clare Liguori",
    "jobTitle": "Senior Principal Software Engineer",
    "worksFor": {
      "@type": "Organization",
      "name": "AWS"
    }
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://linearb.io/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Dev Interrupted - Podcasts",
      "item": "https://linearb.io/dev-interrupted/podcasts"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Agent, skill, or MCP? Which to use and when to use them | AWS’ Clare Liguori",
      "item": "https://linearb.io/dev-interrupted/podcast/aws-clare-liguori-agent-skill-mcp-architecture"
    }
  ]
}
```

[Home](https://linearb.io/)

/

[Podcast](https://linearb.io/dev-interrupted/podcasts)

/

Agent, skill, or MCP? Which to use and when to use them | AWS’ Clare Liguori

# Agent, skill, or MCP? Which to use and when to use them | AWS’ Clare Liguori

By Clare Liguori

|

August 18, 2026

![Blog_Comprehensive_DORA_Guide_2400x1256_76_bb95f7500e](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/Blog_Comprehensive_DORA_Guide_2400x1256_76_bb95f7500e?_a=BAVMn6ID0)

Every engineering team wants to build its own custom AI agent, but what if all your organization needs is a standardized skill or a stateless MCP server? This week on Dev Interrupted, Andrew sits down with AWS Senior Principal Engineer Clare Liguori to untangle the ecosystem of modern agentic architecture. They work through how a team decides which AI building blocks to own, and how to get that reach without inheriting a maintenance burden. Clare shares her perspective on the simplified MCP 7.28 spec and why stripping away heavy custom scaffolding is how enterprise AI scales.

That same shift is what makes MCP a gamechanger for LinearB customers, bringing your SDLC context layer, git, project management, and software delivery, into any agentic surface. What could your agents achieve if they can [query your SDLC](https://linearb.io/platform/mcp-server?utm%5Fsource=podcast&utm%5Fmedium=referral&utm%5Fcampaign=devint-shownotes&utm%5Fcontent=shownotes)?

### Show Notes

* Strands Agents SDK: Explore the open-source framework for building model-driven agents at [strandsagents.com](https://strandsagents.com)
* MCP 7.28): Dive into the new stateless specification at [modelcontextprotocol.io](https://modelcontextprotocol.io/)
* Follow Clare: [LinkedIn](https://www.linkedin.com/in/clareliguori/) | [X](https://x.com/clare%5Fliguori)

### Transcript 

_(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)_

\[00:00:00\] **Andrew Zigler:** Welcome back to Dev Interrupted, brought to you by LinearB. My guest today is Clare Liguori, a senior principal engineer at AWS. She also leads the open source Strands SDK and is a core maintainer for MCP. And this one's a treat for me because we've been following MCP's journey from the very beginning, from its huge initial hype cycle, to its death, to its return, to its now easy-to-adopt stateless form in the recent 728 spec.

\[00:00:27\] **Andrew Zigler:** And Clare is one of the people driving that roadmap behind the scenes, and also building an agent framework born from cross-team needs at AWS. And Clare and I dig into not only the next version of MCP, but what you should be doing now about it as an engineering leader. MCP is a game changer for LinearB customers too, because it brings their SDLC context layer, that's git project management and software delivery, into any agentic surface. What could your agents achieve if they can query your SDLC? \[00:01:00\] Let's find out in my conversation with Clare.

\[00:01:03\] **Andrew Zigler:** Clare, it's really fantastic to have you here because these topics are top of mind for us here on the show, and over the last year you've been pretty deeply involved in all of the stuff that's powering the things that our engineering leaders that are listening are trying to grapple with to transform their engineering organizations.

\[00:01:19\] **Andrew Zigler:** So Clare, welcome to Dev Interrupted.

\[00:01:22\] **Clare Liguori:** Thanks. Let's do it

\[00:01:23\] **Andrew Zigler:** Great.

\[00:01:24\] **Andrew Zigler:** Well, I wanna start at the top with the big, the big item here, which is the Strands Agent SDK. And I gotta say, I've checked out this tool before, and so when I was offered the opportunity to speak with you, I was really excited about it. Because getting to dive into the minds of folks that are, uh, not only building and getting a lot of output from their own agents, but able to express it then into a, a composable modular format that other folks can benefit from, this kind of spreading of the knowledge and getting folks systematized around how these things should work is exactly the kind of movement that we need to see \[00:02:00\] right now.

\[00:02:00\] **Andrew Zigler:** And so, you know, what did it mean to you to come to this project and build this, like, open and composable agent tool, and, and why do you think that this architecture style is, you know, here to stay?

\[00:02:12\] **Clare Liguori:** Well, Strands actually started as an internal project. We had... We were working on it for probably a year before we even initially open sourced it, and we didn't have an idea i- in the beginning to make a, reusable framework for anyone else. We were really just building it for ourselves. Um, I also work on Kiro, our agentic coding assistant, and

\[00:02:36\] **Andrew Zigler:** Yeah

\[00:02:37\] **Clare Liguori:** we built it for ourselves in the Agentic AI org, um, because we were just finding other frameworks to be really difficult to use.

\[00:02:48\] **Clare Liguori:** We found them to be a lot of cognitive overhead for us as developers getting started building agents, and then we had a ton of, work going \[00:03:00\] into production. I actually just saw, um, a little graphic on X this morning that was like, um Prototype, two hours. Production app, two days. Actually getting it into production, six months.

\[00:03:20\] **Clare Liguori:** And that was kind of our that was kind of our experience because we would literally take six months to, to get something into production built on, on other frameworks. And, and so a group of people just kind of started building it, um, internally, and we started applying it to some more projects internally. Um, we launched what was at the time called the QCLI. It's now called the Kiro CLI. We launched that in three weeks, which like to the world public production, and previously that was just unthinkable, \[00:04:00\] right? and I think part of what makes it, part of what makes it easy is that we s- the team spent a lot of time on what is the developer interface for the human and making it really clear and very declarative in a way so that you're really just focusing on the things that matter.

\[00:04:18\] **Clare Liguori:** You're focusing on what model do you wanna use, what, what's your system prompt, what tools do you wanna use, instead of a lot of the other scaffolding that we had been building previously. and then I think we also saw at the time the real shift was agents got... or models got so much better at being agents. And so previously, we had been building up all of the scaffolding around like Sonnet 3.5 to make it do anything reliably in production. Um, and then we saw around the time that Sonnet 3.7 came out, um, we didn't need to do any of that anymore. And even in Sonnet \[00:05:00\] 3.5, we... uh, it was another like leap where we ag- we already didn't have to do a bunch of the stuff we were already doing. so we wanted to just kind of strip all of that scaffolding away and let the model be at its best. we call that the model-driven approach, where let the model do most of the work. Um, I think as engineers, we want to build a lot. We... That's kind of our, DNA is that we

\[00:05:28\] **Andrew Zigler:** Yeah

\[00:05:29\] **Clare Liguori:** And so I see, you know, even inside of Amazon, teams wanting to just build a lot on top of the model, feeling like they're gonna be able to get the best results out of the model if they build more and more on top of it And it's, it's counterintuitive, but it's kind of the reverse, especially because we see these massive leaps in model, um, capabilities every six months, right?

\[00:05:55\] **Clare Liguori:** And so what we would see internally is, uh, we, we would have \[00:06:00\] built a bunch of scaffolding, and then like Sonnet 3.5 came out, and we were making the model actively worse because of all of the scaffolding on top,

\[00:06:08\] **Clare Liguori:** because we weren't giving it the right context anymore. Sonnet 3.7, it would be the same thing.

\[00:06:13\] **Clare Liguori:** But I found is that as you build up all of the scaffolding, we have this very personal connection to the thing, the systems we have built. It is so hard for us to tear them down, especially when their lifetime has only been six months, right?

\[00:06:28\] **Andrew Zigler:** Right

\[00:06:29\] **Clare Liguori:** you know, what we started telling teams internally and what we really built into Strands was this model-driven approach where, you know, assume that in six months you are going t- you should be able to just change a line in your agent configuration to the new model, and now you're fully taking advantage of all of the new capabilities of that model. And especially around, reasoning, tool calling, you know, all of these have made huge strides. Um, and agents, just model-driven \[00:07:00\] agents have become so powerful. Um, but it's, it's hard to do that when you build just kind of this layer of stuff on top and constrain what the model can do.

\[00:07:11\] **Andrew Zigler:** Exactly. There's a lot in there I wanna unpack because you just gave us, like, so much in terms of the, the evolution of where it came from, but also the kinds of things you're optimizing for that I think I, I'm seeing, starting to see a lot of these universe- universal things that are, uh, emerging. So I think it's worth, like, talking about them for a minute.

\[00:07:28\] **Andrew Zigler:** And one of them is that, you know, Strands, it was born out of an internal need, right? It was built to deliver fast for the exact reason of what you said. Like, writing the code and getting the code up has never been easier. Getting it to production now takes a really long time. And even if you did get it to production, understanding then what happened afterwards, what was the impact?

\[00:07:49\] **Andrew Zigler:** Like, actually quantifying the lift of the whole project is exceedingly hard, especially as, as humans are f- further abstracted from whatever it is that you've created \[00:08:00\] as you're trying to justify it and get it across the finish line. So I think that's a really common pain, and I think it's actually, uh, this is something we, we-- when I recently even interviewed, um, one of the lead, uh, uh, he's a distinguished engineer at LinkedIn, and he was a part of the system that kind of transformed all of LinkedIn's internal engineering to be more agentic and be agentically powered, and it all started, you know, out of this, like, need to address these, like, across the board issues with delivery and with consistency and with just ultimately getting a system-wide approach for the organization as a, as a unit to work more efficiently.

\[00:08:35\] **Andrew Zigler:** Not the individual developers themselves, but the whole organization to benefit from the aggregate of all of that working. And a big part of that is having to lean into the simplicity of what the models are capable of doing now and the ways we're able to express them. Because I love that you, you took us through the tour through old memory lane, a very tool happy Sonnet \[00:09:00\] that was, like, so stoked to use tools.

\[00:09:03\] **Andrew Zigler:** It was like just now using tools for the first time. When we had Geoffrey Huntley on the show, you might recognize him. He's the-- he was one of the pr- people at the top of the year who started talking about the Ralph loop. He's the guy who kind of called it Ralph. So we had him here, and he talked about that, and he, he, he was in the same situation as, as you, Clare.

\[00:09:20\] **Andrew Zigler:** He was trying to build something. He had the-- he built this massive kind of system, this big harness that was pushing everything forward, and then it was just dumb loop that was just going and going. And what he learned along the way is that Sonnet just wanted to... was a tool happy, uh, squirrel, was what he called it.

\[00:09:36\] **Andrew Zigler:** Just, like, wanted to. It was dangerous. It was just running on everything and pressing everything. So you had to build all of this crazy stuff to scaffold it. And then there was, like, a step change event that happened at the end of last year that we're all familiar with. Everyone came back. GitHub suddenly couldn't stay online because we're all just, like, running these crazy orchestration flows.

\[00:09:53\] **Andrew Zigler:** And so, the whole environment changes in terms of, like, what we're doing with these tools, and the models just simply \[00:10:00\] get better. And now we're challenged as engineers like, "Whoa, I just spent, like, all that time investing and, and optimizing and getting my cool prompts and defining my sub-agents and doing this whole, like, LARPing thing where, like, I defined all my little people that did all my little things, like."

\[00:10:15\] **Andrew Zigler:** And then we had to wipe all that away

\[00:10:17\] **Clare Liguori:** Yeah

\[00:10:17\] **Andrew Zigler:** simplify our harnesses, simplify our, the ways that our agents work, make it more expressive, make it simpler, make it static. And the static-ness is actually part of what we're gonna talk about a little bit later with, you know, MCP becoming more simplified, but in terms of, like, state and session as well.

\[00:10:34\] **Andrew Zigler:** And so I think all of this kind of things about stripping away stuff that's adding complexity of what we need to turn into a building block, so I think it's really, uh, really insightful to hear that from you with your own experiences. When you make something that's like composable and you steer this as like an architectural philosophy, right, within Amazon, within AWS, this is how we transform our engineering.

\[00:10:53\] **Andrew Zigler:** Like, w- what became like a turning point early in Strands that made y'all understand that like, \[00:11:00\] oh, this is something more formalized than just like it's helping us push thing- throw things over the fence. This is actually something that now maybe is developed and we're gonna open source or share. Like, what, what does that evolution look like?

\[00:11:14\] **Clare Liguori:** Well, we had gone through a couple, I think three projects at that point, three major things that we had shipped into production in less than six weeks, um, at that point. And at that point I said, "We should really put this in the hands of customers," because I think this is, is something that is, um, repeatable now.

\[00:11:38\] **Clare Liguori:** That the success that we're having in, you know, not just building and, and like that initial, time of prototyping something and actually seeing success, but actually getting it into the hands of customers. We've now kind of repeated that for ourselves. we built... Uh, we had kind of an end-to-end, experience for it.

\[00:11:58\] **Clare Liguori:** We had an eval SDK. \[00:12:00\] We had the main SDK. And then we had a lot of, uh, open telemetry observability integrations. and so we, we put it in preview and we weren't really sure, you know, how it was gonna be received, right? Um, this is a super crowded space. Um, but it was really exciting to see, even just when we were in preview, people telling us how quickly they were able to move with it.

\[00:12:25\] **Clare Liguori:** I remember, a particular customer reached out to us maybe two months into the preview and said, "Hey, I took a goal to have, like, 25% of my traffic go through agents." this was like June. And he said, " And we picked up Strands, and we pushed an agent to production in a month, and we just completed the goal in the middle of the year."

\[00:12:52\] **Clare Liguori:** Um, and so that was... I think that was a really exciting point for me, just me personally, right? Of like, yes, other people are seeing the \[00:13:00\] same success that we are. I think that the world has, you know, is always evolving as you, as you pointed out as well. Um, and so the-- since we launched initially last... Not last May, because now it's over a year ago. I

\[00:13:18\] **Andrew Zigler:** I'm willing

\[00:13:19\] **Clare Liguori:** we had our one-year anniversary the, just in May.

\[00:13:22\] **Andrew Zigler:** Happy birthday, Strands

\[00:13:24\] **Clare Liguori:** the, the, you know, the fall of last year, the winter of last year when, when harnesses became the thing, right? and that's a point where I started to see, kind of an interesting transition in like thinking about who should build agents from scratch. Um, because all of a sudden, our coding assistants are super powerful, right? Um, so maybe you don't need to build like an on-call troubleshooter agent from scratch anymore because, we were seeing thousands of people just do like a little custom agent config with \[00:14:00\] their coding assistant with Kiro internally. And so you wanna be able to build this kind of harness platform internally is, is the best way that I can describe it. I think previously what I used to see is In large organizations, not just scale in terms of like number of transactions per second, but in, in terms of scale in terms of complex organizations, Conway's Law has been applied to agents very much,

\[00:14:27\] **Andrew Zigler:** Yeah

\[00:14:28\] **Clare Liguori:** in the sense of agents become... the number of agents you ship maps to your organizational architecture So every team feels like they have to own an agent, that, you know, they're gonna take a goal this year on building an agent. And I've seen this internally at Amazon, but also at our customers, which I'm starting to hear from, from AWS customers that, "Hey, I have 500 agents across all of these teams internally," and that just seems like too much these days. Um, you really don't have to \[00:15:00\] constrain agents so much. I think there was previously a, um... And there's some pockets that, that still feel like you should build micro agents, that you should build these very domain-specific agents that only have like one or two skills. But I think since we've seen these massive leaps in models, and especially with things like progressive disclosure, you just don't need that anymore. and so... But, but y- still you have the organizational problem of everybody feels like they need to build an agent, when really, many, many products really just need one agent and a bunch of tools and skills that are progressively disclosed. And so internally within Amazon, we recently GA'd, I think last month, the AWS MCP server. um, this is a great example where we had hundreds of MCP servers published by individual service teams.

\[00:15:54\] **Andrew Zigler:** Mm-hmm.

\[00:15:55\] **Clare Liguori:** everybody was kind of eager to build an MCP server for a while internally. And \[00:16:00\] then, um, and then we, we came together and we said, "Hey, we actually don't need that many MCP tools. What we need is skills to teach models how to use the AWS APIs," uh, because there are 16,000 of them.

\[00:16:14\] **Clare Liguori:** And so um, it's actually very difficult for a model to reason about the AWS APIs. Um, and so that's what we, that's what we built. We built a remote, um, HGP MCP server that, uh, exposes a number of skills that are owned by individual service teams about how best to use their APIs, right? Um, but that's what I've been talking to a lot of teams internally and a lot of customers of, you know, thinking about whether you need to build an agent as an individual team, or maybe you just need to own a skill.

\[00:16:47\] **Clare Liguori:** Or maybe you just need to own an MCP server or a collection of tools in an MCP server.

\[00:16:52\] **Andrew Zigler:** Yeah, that really resonates with me because that's actually something at, at LinearB we've talked about too as well, with how we've, you know, built and \[00:17:00\] distributed our, our internal services and MCP servers and skills, and everyone does want to own one. I really loved how you related the agents to Conway's Law, that it's reflected in your org chart.

\[00:17:11\] **Andrew Zigler:** Like, it couldn't be more true. I, I really find that to be the case, uh, when I talk with folks at their organizations, that it is true. Most teams do wanna take it upon themselves to own an agent. It feels like a part of an org chart that they feel justified to have and that they

\[00:17:25\] **Clare Liguori:** Mm-hmm.

\[00:17:25\] **Andrew Zigler:** would, you know, enable them, help them be better by other teams, and everybody wants to just, like, deliver more, right?

\[00:17:30\] **Andrew Zigler:** So I think that's a familiar pain, or rather a familiar aspiration that then turns into a pain, because then internally it's like, oh, we have, we have this big tangle of all of these different systems and processes, and everyone's on a different, on a different page, right? It goes back to, to what I was saying earlier about how you kinda get these individual developers that are, like, super agentic and can like, you know, be in the fast lane and get a lot delivered, but they have a hard time translating that into their peers or their team \[00:18:00\] or into an organizational composable thing.

\[00:18:02\] **Andrew Zigler:** Or you find that there's this person over here and this person over here, and they're doing kind of the same thing, and they've made this whole world of tools, but they've never talked to each other. And

\[00:18:11\] **Clare Liguori:** Yeah

\[00:18:11\] **Andrew Zigler:** and so it's like, oh gosh, it's like, uh, creating an ecosystem to bring all of that together I think is the biggest challenge for engineering leaders.

\[00:18:18\] **Andrew Zigler:** I think it's really salient that folks are asking you that or bringing that to you in conversations because, uh, like even when we t- I talked with James Everingham, who's now leading Guild AI, he was the head of dev infra for Meta during part of their agentic transformation, and he labeled that as one of their, like...

\[00:18:35\] **Andrew Zigler:** It was the biggest internal change that they possibly could have made, was to create an internal ecosystem where people could bring workflows, bring skills, bring MCP servers and agents, and bring into one shared layer so that there was no more duplication. And now folks that had similar minds were organizing into guilds around stuff that they were interested or, or were specialized in, and, uh, they just got a lot more \[00:19:00\] organizational gains, um, and it brought everybody to the table.

\[00:19:03\] **Andrew Zigler:** He was talking about, like, folks on, like, account payable that were, like, making agents. It's like people, everyone was at the table. And so, um, I think that's a really powerful strategy, and I think part of that challenge too for folks is you get into this tangled web of, oh, we have this whole, you know, dark web, like mass of like AI stuff going on in our, in our org.

\[00:19:22\] **Andrew Zigler:** Let's like figure out where all the humans are in relations to this stuff as well, because, uh, you have organizations wanting to make sure that there's a appropriate oversight and expertise, uh, in the loop. And it really just depends on like what the loop ultimately looks like for like what you're delivering and what your agents are doing.

\[00:19:42\] **Andrew Zigler:** Like I know for us, like at LinearB, especially with our customers, like the loop is the terminus or like the beginning of the next is like the, the merge boundary, right? We're looking at the AI's effect creating code and ultimately merging and delivering and then what happens afterwards. But you have to have this point where then \[00:20:00\] at that merge boundary where you're doing a PR review, is it a human reviewing it?

\[00:20:04\] **Andrew Zigler:** Is it an agent reviewing it? Is it both? Or are, is it an agent that's taking the cognitive load off of the human and elevating to the human on these part- specific criteria? Like, these are the kind of automations and stuff that I think like folks that are trying to crave a control again over their SDLC are really, really looking for when they, when they come to us at LinearB.

\[00:20:24\] **Andrew Zigler:** And so it makes sense that like a folks who would be building and distributing these agents and trying to like corral it would have that same kind of question. Like what is, what, what do you think about in terms of like the, the terminus of the merge or the loop, right? Like what does the loop look like and where do you think the human should be inserted most of the time?

\[00:20:41\] **Clare Liguori:** We call this, um, frontier engineering at, uh, at Amazon because we're really seeing, know, I think over the last, um, three years that I've been invol- or three and a half years that I've been involved, we've gone from, you know, these inline code completion where it's \[00:21:00\] just helping you to write the next line or maybe the next function.

\[00:21:04\] **Clare Liguori:** And then we started, chatting about our code, like asking, "What does this code mean?" then we started vibe coding, but I think across all of that, none of us really felt m- that much more productive. Like, not a step function change in production, like, uh, productivity. And now I think, you know, as you were talking about these really nat- AI native folks, we're, we're literally seeing based on... We're doing some pilot-- We've been doing pilots with different teams, uh, four to five X productivity increase. I mean, it's am- it's amazing what, what now with these newer models k- since kind of the winter of last year that we're, that we're able to get. But we're also seeing there are, um, some real practices that they put in place.

\[00:21:52\] **Clare Liguori:** Like, it's not just about the tools, right? It's about the practices and the, the change in habits that they've been making. Um, but one \[00:22:00\] of them is around accountability of quality of code, because I think that... I used to say the thing that a new hire will always do coming in do something wrong with Git. Right. They'll try to do

\[00:22:17\] **Andrew Zigler:** Guilty. Guilty. New h- new hire here. I,

\[00:22:20\] **Clare Liguori:** right?

\[00:22:21\] **Andrew Zigler:** it comes in, you go in, you clobber git. And it's like, it's li- it's the ritual

\[00:22:24\] **Clare Liguori:** But now ev- people coming in, it's always an AI slop pull request.

\[00:22:31\] **Andrew Zigler:** Oh yeah, so it's, it doesn't hit the same, right? It doesn't feel as good. You're like, "Oh no

\[00:22:36\] **Clare Liguori:** we, we have, we have to be accountable as, I, you know, I tell teams, "You have to, you have to take accountability for the code that you produced, even if you generated it using a model or if you wrote it by hand, you have to take the same accountability." Um, and so typically, like on the teams that I work with we assume that you have read it before \[00:23:00\] you push it to pull request.

\[00:23:02\] **Clare Liguori:** Um, often those slop ones are like, you know, the person's coding assistant just pushed it. Um, and the human never looked at it. Uh, but then we also have been doing a lot with, um, automated AI code review to catch the total slop, but also to catch the nitty-gritty stuff that we shouldn't have to look at anymore.

\[00:23:27\] **Clare Liguori:** Like, Is this maintainable? Is this t- Do you... Did you add tests? Do the tests make any sense? Um, and then we get to focus in the pull request on, are we doing the right thing here? Is this the right thing to do? Is this touching very sensitive code that tend to break in production if we change it?

\[00:23:48\] **Clare Liguori:** Like, all of those types of things where, they're really important stuff, but that I think people in code, in manual code review have tended to miss the forest \[00:24:00\] for the trees. I think we

\[00:24:01\] **Andrew Zigler:** Yeah

\[00:24:01\] **Clare Liguori:** who's very nitpicky in

\[00:24:03\] **Clare Liguori:** code reviews

\[00:24:05\] **Andrew Zigler:** Mm-hmm.

\[00:24:05\] **Clare Liguori:** And, and doesn't really t- you know, look at the, the overall picture of like, is this, is this the right thing to, to push? Um, and now the AI gets to be picky for us, right?

\[00:24:18\] **Andrew Zigler:** Right

\[00:24:18\] **Clare Liguori:** the, and the AI code reviewer and your AI code generator get to chat with each other.

\[00:25:05\] **Andrew Zigler:** I wanna dig into some of that 'cause that's really fascinating. The, uh, so on the submitter side, like the code producer side, there's an ownership value. You have to read it. You're owning the code. Doesn't matter if you wrote it, your agent wrote it, that's a great universal value, and then you bring it to the team.

\[00:25:20\] **Andrew Zigler:** And then, uh, you flagged, uh, like then you can have something like an AI review come in and look at the PR before a human and take care of those nits and check for tiny things, and even like code smell stuff. Like did you add new code or did you refa- go and find the thing you should have refactored and refactored it or figured out what was dependent?

\[00:25:39\] **Andrew Zigler:** Did you just like choose a shortcut? 'Cause that's like, I think a really big challenge, especially in like bigger, more brownfield code bases as well. So, in that world, are all of those PRs typically getting an AI code review first? Is that like a pretty much an expectation at this point?

\[00:25:54\] **Clare Liguori:** Yeah. And, uh, a- and I think, but I think like you said, um, the \[00:26:00\] challenge in a large organization is are we sharing the prompts of, of these AI code reviewers, right? Um, are... Is it, is it getting installed across everybody? And, um, we have built internally some good mechanisms around that. We have something, called...

\[00:26:20\] **Clare Liguori:** It's called AIM. I it's kind of like a, like an NPM install kind of, where you can install custom agents, you can install MCP servers, you can install skills onto your local, um, machine. And so that's a great way for organizations as a whole to do that. And we've seen everybody struggling with this, like all large organizations, because for the last 25 years, we have been, you know, fed the gospel of service-oriented architecture, and now we're just shoving markdown files around. Right? And so, um, like some

\[00:26:57\] **Andrew Zigler:** Or

\[00:26:58\] **Clare Liguori:** order has to

\[00:26:58\] **Andrew Zigler:** if you're fancy.

\[00:26:59\] **Clare Liguori:** \[00:27:00\] Yeah, exactly. Like I'll, I'll upload it to Slack for you, you know, but we also have some, you know, the hooks into your code review system is also really important. And so we have this thing called, um, it's called Auto SDE, but it's effectively, you know, anybody could, could implement kind of a custom agent in GitHub actions, right?

\[00:27:21\] **Clare Liguori:** To, to go and, and review a, a pull request and add comments.

\[00:27:26\] **Andrew Zigler:** Right. But that's just like almost a necessity now because of the volume of code that's moving through the code base now, it's just so much higher. You're, and you're definitely seeing that fire hose, right? You can't, you couldn't even drink from it if you wanted to.

\[00:27:38\] **Clare Liguori:** Right.

\[00:27:39\] **Andrew Zigler:** ha- and so like having also control over or standardization around the review prompts, how things are getting reviewed, what matters, I think that organizational level standardization's really important.

\[00:27:50\] **Andrew Zigler:** It's definitely why teams definitely would turn to like tools that standardize that, right? I think that's a really critical thing. And another thing too is like, um, even thinking in the future about \[00:28:00\] like, "Oh, okay, what's the, what's the prompt going into my AI code review? Okay, but what was the prompt that made the code?

\[00:28:06\] **Andrew Zigler:** Where does that live in here? Or where does the whole conversational logging?" That's what like I'm seeing like really cool takes on the GitForge starting to come out. Like the GitForge obviously has to be reborn, you know, from the ashes. It needs to be more agentic. More stuff frankly needs to live in it, and you got companies like Entire really trying to tackle that problem.

\[00:28:27\] **Andrew Zigler:** So I think we're gonna see a lot of interesting developments. But, um, my, my last thing I wanna pull from your head on this, like do you think the GitForge is insufficient? Do you definitely think it needs to change too?

\[00:28:37\] **Clare Liguori:** I do. I think a lot of the work out there right now is focused on kind of the storage problem, the s- the scale of, of changes. Um, and it's interesting, uh, Git has been misused as a database for a long time.

\[00:28:56\] **Andrew Zigler:** Say it louder. Say it again.

\[00:28:59\] **Clare Liguori:** we, \[00:29:00\] we've gone through GitOps, where people are trying to use git reverts as production rollbacks and things. Um, and so, I mean, one of my hopes is that we come out of this with an actually good database for handling these things, because we're starting to see, you know, for use cases that do really need multi-agent architectures or even when you have multiple agents working in parallel on the same, like, workspace or code base or whatever it is, and the same data, basically, they're gonna run into conflicts, and you have to resolve those conflicts.

\[00:29:36\] **Clare Liguori:** And, and engineers are extremely comfortable with Git conflict resolution, right? Um, and so anyway, I hope that we come out with nice database solutions around this. But I also think that the code review process has to change, right? and we're kind of working around the current experience right now, but it seems crazy that we \[00:30:00\] have...

\[00:30:00\] **Clare Liguori:** We now have, you know, multi-thousand-line code reviews, and we are still just kinda putting that all on the page in,

\[00:30:09\] **Clare Liguori:** in Courier New right? And so, um, I think that there's, there's a lot of room for, for improvement around the, just the experience of the life cycle of the code as well.

\[00:30:21\] **Andrew Zigler:** Oh yeah, the PRs just become like theater. You go in and it's like stamp, stamp, stamp, stamp, stamp with a bunch of, you know, big long blocks, and people aren't even reading the CICD. There's a whole refactor there that's, that will be due. But when it happens, Clare, I guess you and I will have to reunite and then, you know, gossip about it then.

\[00:30:34\] **Andrew Zigler:** But, but you know, I, this episode is gonna be coming out a little bit after when this happens, but we gotta talk about it because it's still gonna be a hot burning topic when this episode does drop, and that's the MCP 7.28 formalization around the spec, which you are obviously playing a big part in as a core maintainer at MCP.

\[00:30:52\] **Andrew Zigler:** Um, I'm super excited about this. I'm, I'm one of the, um, AAIF ambassadors this year, and so I've been also out there sharing the \[00:31:00\] news about how the spec has been changing and what folks need to do to get prepared, and actually how much simpler it really is gonna be for all of us. I'm super stoked, but I, I wanna know what you're stoked about.

\[00:31:09\] **Andrew Zigler:** Like, what's top of mind for you as a maintainer about what is gonna be coming, uh, with the 7.28 change?

\[00:31:15\] **Clare Liguori:** Well, the first big one is how much easier it's going to be for people to build remote MCP servers with the HTTP transport. I think that have long been a proponent of getting out of the standard IO MCP server game. I think that really any SaaS provider should have an MCP endpoint for their APIs. Uh, but it's been hard so far. It's been really difficult to do anything, in the MCP to implement anything as a, as a remote server provider other than basic, basic tools. Elicitation is a great example, where as an MCP server owner, you \[00:32:00\] can respond back with a form or a URL that you want the user to go and fill thing, fill more information out and respond.

\[00:32:09\] **Clare Liguori:** And that has been impossible so far because it required the server to be super stateful. Um, and that's just... And it's, we've heard the feedback loud and clear from lots of people that that's hard. And it, it is hard, um, to build a streaming API into your web server, um, in order to support things like elicitation.

\[00:32:32\] **Clare Liguori:** And so my hope at least is that now that we're transitioning to a much more stateful or stateless design rather, with much more typical request response patterns in requests, that, um, people are going to be able to embrace a lot more of the spec, um, that they're going to be able to implement elicitations because now it's, it's really simple to do a request response, typical API \[00:33:00\] pattern.

\[00:33:00\] **Andrew Zigler:** Yeah, it sounds like you're taking the, the same strategy to it that you took the things that we talked about earlier in our chat, simplifying it, right? We have this opportunity of taking things away. MCP used to have to be this stateful thing that was basically, you know, like, uh, like someone with like a newspaper spec in the agent when it would do something wrong or otherwise, like it would had to just...

\[00:33:20\] **Andrew Zigler:** It, it had a whole different approach. It was in a whole different world of models and harnesses. So for it to be more, it's like coming in and just kind of trimming out what isn't really contributing, what's actually holding folks back. Because you pointed out a key thing that has been something that's plagued the MCP spec and its adoption more broadly, is that it's hard to produce and serve this streaming server, like at scale, and it makes it hard for folks to go beyond internal usages as well.

\[00:33:47\] **Andrew Zigler:** And so because of that, this opens then the opportunity for those teams to reevaluate MCP as a step changer for their own products, for their internal workflows, and ultimately it just makes it \[00:34:00\] more, uh, capable because you're taking away stuff that doesn't work. So do you feel like more about like this release is more about simplifying than adding things on?

\[00:34:09\] **Clare Liguori:** I think so, and I think especially for, uh, you know, the developers that are building on top of MCP, right? That's really my hope is that, um, it's simpler for people that are building on top of it. I think the other one, the other piece is, in terms of simplifying, is figuring out and getting better signals around what is really working in the MCP, uh, protocol. So, uh, one example is that, uh, tasks has been in the, in the spec as kind of this experimental thing. Tasks, uh, allow you to model long-running jobs through MCPs. You can kick off a task and then see the status of a task, and then, um, get a task completion, \[00:35:00\] as opposed to a tool, which is very, you know, request response, typically pretty short-lived. but it's... There's been a bunch of changes to it and as we've gotten feedback, and so that has created, I think, a lot of churn for folks. And again, we need, we need to make it simple and easy and straightforward to build on top of this, this protocol. so we moved tasks to, uh, an extension, and we already have a set of extensions.

\[00:35:26\] **Clare Liguori:** MCP Apps is an example where the server can provide a UI, a full UI widget. it's supported in ChatGPT, for example. but it's, it's, m- you know, an extension could be something that is pretty mature, but is a p-pretty particular use case that is not necessarily going to get promoted into the main spec. But it can also be for experimental things where we can make breaking changes. We don't want to make a lot of breaking changes in the main spec. We want it to be very stable. But we also... You know, the space is moving fast, and \[00:36:00\] we wanna experiment with some of these new ideas, like tasks. Uh, I'm also working on, um, MCP events and webhooks but we wanna make sure that we design it right, that we design it in a way that people can actually easily build servers, easily build clients and harnesses on top of it. And so moving forward, what you'll see is a lot more extensions and then things kinda graduating into the spec as they become more stable and as we see more real-world usage of them.

\[00:36:29\] **Andrew Zigler:** Yeah, I think that's a, a great way to kinda chart how the spec is going to evolve. First we have this simplification stage. We're gonna make it just easier for everyone to build with the baseline parts of this tool that are transforming agentic workflows now. Let's get this simple now. And then we create these opt-in experimental kinds of add-ons, these working groups, these communities that expand it, that find these things that are durable and actually have a lot of cross-industry uses, and let's formalize it, 'cause that's the point of having the open spec, the open protocol.

\[00:36:59\] **Andrew Zigler:** And \[00:37:00\] MCP Apps is a big one. We've talked about that a lot on the show. We followed it actually in its infancy when it was very, very first kind of announced, obviously for its shopping use case, because why else would you be making MCP Apps? And so we've then followed it to its recent fruition with the, the chief product officer at Slack, Jamie DeLange.

\[00:37:18\] **Andrew Zigler:** You know, they're integrating MCP pretty deeply and MCP Apps into their, uh, system as well, and it's been pretty transformative for like br- 'cause you bring like these UIs, iFrames, and React to the whole world of the web that we're already really familiar with and already really fluent with, and then you can bring it into the conversation.

\[00:37:36\] **Andrew Zigler:** I think that's a, a big unlock for teams to build these more composable workflows. And then that I think then, at least for me, starts to shine a light on when and why as an organization would I have an MCP server over a skill or an agent? When do, when do I choose which to own? And, um, which goes back to the earlier thing as you said as well, because all of those \[00:38:00\] things can just be next level contributions to the team without having to be like the agent, right?

\[00:38:05\] **Andrew Zigler:** So, uh, th- the idea of, uh, being able to more simply build a skill versus an MCP server, and they have their very separate use cases, is something that then becomes more clear because, oh, I use MCP to serve these very distinct tools or internal visual experiences or to up- or to then stand upon the platform of my skills that my organization has managed to standardize.

\[00:38:30\] **Andrew Zigler:** So they, they have like a synergy to them. How do you, how do you think about MCP and skills and, and untangling them for engineering teams?

\[00:38:37\] **Clare Liguori:** are, they are definitely complementary. Um, there is right now an experimental extension for skills over MCP. One thing that we see a lot is that skills describe how to use MCP server tools. Uh, as I was saying, we have this AWS MCP server, which you can call sixteen thousand \[00:39:00\] AWS APIs through. Um, and, and you can do, you know, thousands of things. And, and a lot of the things that you, that you wanna do through those APIs requires multiple API calls in a particular sequence, right? I wanna stand up a serverless app. That's gonna require who knows how many AWS API calls. Uh, and so we have this list of...

\[00:39:20\] **Clare Liguori:** We, we surface skills through this MCP server to describe how to use the other tools on the MCP server to do very specific things. If you wanna-- You know, in the description, we get to say, "If you wanna build a serverless app, or you are, you know, troubleshooting something about an RDS database, um, call these APIs or call these APIs."

\[00:39:41\] **Clare Liguori:** And that's kind of the beauty of progressive disclosure, right? Is you definitely do not need all of that content at

\[00:39:47\] **Clare Liguori:** once.

\[00:39:47\] **Andrew Zigler:** Right, right,

\[00:39:48\] **Clare Liguori:** and there could be thousands of them, right? And so, uh, we've, we've heard a lot of use cases in the community, the MCP community around, I wanna describe \[00:40:00\] different use cases of how to connect these different MCP tools together for the server. Um, and that makes a ton of sense if you are using it internally, an internal MCP server or you're a SaaS provider and you wanna provide, you know, great ways to use your APIs for agents. Um, we also hear a little bit of people having trouble, wanting a package manager for skills, um, and trying to use MCP for that.

\[00:40:26\] **Clare Liguori:** I think that's a little bit different. But

\[00:40:28\] **Andrew Zigler:** That's a really big challenge for teams. How do we, how do-- You know, we could just chuck it into git, but then, you know, you'll have a lot of folks that are making and using skills that aren't anywhere near git. So it's like, it's very hard to distribute it.

\[00:40:39\] **Clare Liguori:** That's right. That's right. Yeah, I do like the MPX skills, tool from Vercel, but, um,

\[00:40:45\] **Andrew Zigler:** Yeah

\[00:40:46\] **Clare Liguori:** yeah, it does then re- rely on Git. And then we, we always have to remember not everybody is a developer who's using agents, right?

\[00:40:53\] **Andrew Zigler:** That's the, that's the thing. We have to make these tools more accessible, and you're right that they are very complementary. MCP brings the \[00:41:00\] distribution, and then Skills bring the capability. And for me, myself, I use Skills over MCP. I'm a user of that experimental plugin because I do find that to be a great synergy.

\[00:41:10\] **Andrew Zigler:** The progressive disclosure, as you've called, is, uh, really what's so critical about working with these tools is, you know, they are so powerful, but-- and they have big context windows, but if you clobber them, then you're just not gonna get the results you want. But also, more crucially, if you clobber them, then they're not gonna know what to look at.

\[00:41:30\] **Andrew Zigler:** So the progressive disclosure actually allows it to reason better. It thinks between the things that it learns, and those kinds of tiny changes with our tools are super critical. Um, and MCP is obviously playing, paying a big part in that. So just to kind of round out our conversation here, if you were to say something to an engineering leader right now whose teams have maybe been experimenting with Skills and MCP in particular, they're having trouble standardizing, what should they pay attention to right now?

\[00:41:59\] **Andrew Zigler:** What \[00:42:00\] strategies can they take back to their teams to get ahead based on the stuff that you're seeing in shipping?

\[00:42:05\] **Clare Liguori:** I think one is always think about simplicity. We have arrived at a time where the models are simply amazing of what they can do, and so building... focusing on building out context, whether that be a tool that goes and gets context or, or takes an action or a skill that provides context about using tools, whether that be a s- MCP server or a CLI or an API, um, that's really the thing to, to focus on now because the, the context is what makes all of that, all of this work.

\[00:42:41\] **Andrew Zigler:** Amazing. Well, Clare, thank you so much for joining me today and taking a deep dive into the Strands Agent SDK, but also a tour through MCP and its evolutions, and even, like I said, a trip down memory lane. We got to reflect on how the models and the tools used to be and how they are now, and how good we really do have it now compared to \[00:43:00\] then.

\[00:43:00\] **Andrew Zigler:** I think the challenge for everybody to, to strive for simplicity is something I say all the time on Dev Interrupted. I couldn't resonate with that more. Uh, and just as we round up here, Clare, where can our listeners go to learn more about you and your work, uh, and everything that we chatted about today?

\[00:43:15\] **Clare Liguori:** Well, you can go to strandsagents.com to learn more about Strands Agents SDK, and then, um, I hang out on X and LinkedIn

\[00:43:25\] **Andrew Zigler:** Amazing. Well, we're gonna tag you on LinkedIn. Uh, we also are sometimes shared around on X as well. And so I... And for our listeners, if you're listening to us, you know, on a podcast provider like Apple or Spotify, be sure to leave us a, a like or review. If you came all the way to the end of this chat, then you're obviously a big MCP nerd like Clare and I.

\[00:43:44\] **Andrew Zigler:** So please come and find us on LinkedIn. Tell us what you thought about today's episode. Drop a comment on the Substack and LinkedIn newsletters that accompany it as well, and we'll see you next time. Thanks again for listening to Dev Interrupted by LinearB. And Clare, thanks again for coming on the show.

\[00:43:59\] **Andrew Zigler:** It \[00:44:00\] was an absolute pleasure chatting with you.

\[00:44:02\] **Clare Liguori:** Thank you.

## Real conversations with top engineering leaders

Find us on

[](https://www.linkedin.com/showcase/dev-interrupted/)
[](https://devinterrupted.substack.com/)

## Your next listen

[![Cover image for Telling your agent “no” is a moat now, rearward deployed engineers, and harnessing the context for your SDLC](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/ai_agent_workflows_engineering_context_management_82ca8af964?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/podcast/rearward-deployed-engineers-claude-code-auto-mode-sdlc-context)

Dev Interrupted

[Telling your agent “no” is a moat now, rearward deployed engineers, and harnessing the context for your SDLC](https://linearb.io/dev-interrupted/podcast/rearward-deployed-engineers-claude-code-auto-mode-sdlc-context)

This week on the Friday Deploy, Ben and Andrew break down Uber's strategy of rearward deploying engineers to scale agentic workflows across non-technical...

[![Cover image for The playbook to close your team’s AI productivity gap | LinearB’s Yishai Beeri](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/Blog_Comprehensive_DORA_Guide_2400x1256_74_0278e11de6?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/podcast/linearb-yishai-beeri-2026-ai-productivity-gap-pr-yield)

Dev Interrupted

[The playbook to close your team’s AI productivity gap | LinearB’s Yishai Beeri](https://linearb.io/dev-interrupted/podcast/linearb-yishai-beeri-2026-ai-productivity-gap-pr-yield)

LinearB CTO Yishai Beeri joins the show to unpack 2026 benchmark data from 2.7 million PRs, exposing a widening productivity gap across engineering teams....

[![Cover image for Model welfare, building a civilization for agents, and the CI/CD landrush](https://assets.linearb.io/image/upload/c_limit,w_3840/f_auto/q_auto/v1/_797274efda?_a=BAVMn6ID0)](https://linearb.io/dev-interrupted/podcast/steve-yegge-agentic-civilizations-ai-harnesses-cicd)

Dev Interrupted

[Model welfare, building a civilization for agents, and the CI/CD landrush](https://linearb.io/dev-interrupted/podcast/steve-yegge-agentic-civilizations-ai-harnesses-cicd)

On this episode of the Friday Deploy, Ben and Andrew break down Steve Yegge's radical approach to building agentic civilizations and pushing code straight to...

## Structured data

_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LinearB",
  "url": "https://linearb.io/",
  "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
  "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
  "sameAs": [
    "https://www.linkedin.com/company/linearb"
  ],
  "award": [
    {
      "@type": "Award",
      "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
      "dateAwarded": "2026",
      "awardedBy": {
        "@type": "Organization",
        "name": "Gartner®"
      }
    },
    {
      "@type": "Award",
      "name": "Great Place to Work Certification",
      "dateAwarded": "2025-2027",
      "awardedBy": {
        "@type": "Organization",
        "name": "Great Place to Work"
      }
    },
    {
      "@type": "Award",
      "name": "America's Best Startup Employers 2025",
      "dateAwarded": "2025",
      "awardedBy": {
        "@type": "Organization",
        "name": "Forbes Magazine"
      }
    }
  ],
  "hasCertification": [
    {
      "@type": "Certification",
      "name": "SOC 1 Type 2"
    },
    {
      "@type": "Certification",
      "name": "SOC 2 Type 2"
    },
    {
      "@type": "Certification",
      "name": "GDPR Compliance certification"
    },
    {
      "@type": "Certification",
      "name": "ISO 27001"
    }
  ]
}
```

## More on linearb.io

### Top navigation

- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Register now](https://linearb.io/event/the-great-software-factory-debate-2)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB Library](https://linearb.io/library)
- [Engineering metrics](https://linearb.io/library/engineering-metrics)
- [Platform engineering](https://linearb.io/library/platform-engineering)
- [Engineering glossary](https://linearb.io/library/engineering-glossary)
- [Developer productivity](https://linearb.io/library/developer-productivity)
- [AI in software development](https://linearb.io/library/ai-in-software-development)
- [Engineering management](https://linearb.io/library/engineering-management)
- [Developer experience](https://linearb.io/library/developer-experience)
- [DevOps](https://linearb.io/library/devops)
- [Engineering operations and the context layer](https://linearb.io/library/engineering-operations)
- [Engineering efficiency](https://linearb.io/library/engineering-efficiency)
- [Software delivery](https://linearb.io/library/software-delivery)
- [Research and data](https://linearb.io/library/engineering-benchmarks-and-research)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)

### Footer

_Additional links from the site footer, not repeated from the top navigation above._

- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)