Michael Angstadt

VP of engineering for ClosedLoop AI.

You know, it's a bit of a change, certainly. Meta into Atmosphere, spent quite a bit of time in advertising, and so it was neat to get into the healthcare space, and even neater now with sort of the advent of AI, the big pivot our company's doing in the productivity software, and the sort of special sauce that got us where we were with the healthcare app, now being able to take that to other companies.

Yeah, so ClosedLoop AI is an eight-year-old, what I'd like to say, old-fashioned AI company, and so kind of got our success with a risk stratification platform, helping health insurance companies process claims and whatnot. From that, we had a sort of additional add to the portfolio of a healthcare app, taking all of those industry relationships we had, the success we had in sort of the deep roots of modeling and data science, and paying that forward to how can we improve healthcare outcomes for Medicare patients, be able to extend doctor's offices and not replace them, but give them tools to help scale and really make sort of an AI two-way swinging door between you and your doctor. So be able to be informed with your medical records, every MRI you've ever had, even the notes from your last doctor's visit, and be able to have a chat experience.

December, January, ChatGPT came out with Health GPT, caught us from behind, not only with a sort of retail offering for B2C, but also an enterprise offering for hospitals, administration, et cetera. So we made the hard decision to sort of go back to the drawing board and say, "Okay, what's working with the company?" And what was working is that we went from sort of what I'll call terrestrial speed of engineering and sort of traditional planning, story pointing, backlog refinement, and went 300% faster by leveraging AI tooling, building our own multi-agent orchestration platform off the back of Claude Code. So doubling down on that and now scaling that out and offering that out to other companies as well.

Absolutely. We've seen a huge paradigm shift in shifting left. When you look at traditional story-pointed tickets, what you would bring into a traditional scrum agile process, the time and energy you can spend on a daily basis and a daily stand-up, sharing context of what are you working on, what's next, where you're at in the process — all of that is sort of in the past.

A lot of people don't realize Scrum.org, Scrum in general, that's from 1993, over 35 years old. Do you know anybody that uses a 35-year-old computer or a cell phone? Definitely not. So in terms of something I think we've just as an industry gotten stuck in, we've really been able to see a paradigm shift in thinking about what traditionally would be an epic or an initiative being a bite-sized piece of work now for an engineer. It's a lot more important about making sure you're defining the work and planning it in an appropriate way, making sure it fits within your architectural guidelines, it's collectively exhaustive and mutually exclusive so you can concurrently have more than one person work on it. Some of those lessons that we've learned from both a process standpoint and the actual technology, we've sort of bundled up and now are making readily available.

So far so good. Lots of success. We've actually just released the sort of core of the bit, which is our Claude plugins. These are open source plugins, very similar to a lot of orchestration frameworks you see out there. But that's not nearly as exciting as what we've got in store. That really is the single-player aspect of things. You see this a lot in agentic workflows or management, things like AgentTown or get-shit-done frameworks. These various frameworks that are coming out and people are posting open source on GitHub — it's all about me as a single player.

How do I have multiple agents sort of synthesize or provide a synthetic team for me in different aspects and ratios, critiquing, judging each other, et cetera — that's where we see a real opportunity. A lot of people aren't focused on how you take a team of 25 engineers and make them act like 250 engineers. How are you collaborating effectively? How are you reviewing things properly? How are you doing all the same things that got you great code six, 12 months ago, but now just doing it in larger chunks and bigger pieces?

Right, exactly. I think that's the part about signal that we're looking at. You can certainly have an LLM judge how good an artifact of an LLM is in and of itself. But where we really find meaning is being able to plug in the production sources of signal and telemetry observability that you've already been using. So being able to plug in and not tune for, change this code until a code review doesn't find any issues, but change this user experience until PostHog user retention goes up, or change this code until the CPU metric in Datadog is up or down. By being able to have those signals that are the actual results, it's self-learning the same way that it would find a bug or a linting issue.

No, this is 100%. So we are probably on the bleeding edge or leading edge of adoption here. We are not testing anything with human beings. We look at every human in the loop as friction, and you look at those transitions and go, okay, what value is the human being adding at this step? Are we making a decision? Are we providing direction in terms of taste? Those are the things that are difficult for an LLM to still do. In terms of execution steps, we're taking something like exhaustively do a Monte Carlo simulation on multiple variants of the prompt until CPU is within 5% of our thresholds — hand that off to an LLM all day and let it churn.

So from a single standpoint, I think it does depend on what you're trying to solve. But for things you do have good signal for — user retention, e-commerce, any sort of golden signals around telemetry infrastructure — you can pipe that right back in and have the same solve-for as you would in any other artifact-bound non-deterministic system.

I think at the end of the day, you need to decide what work you're going to do. What features do you add? What is a priority? When essentially it rounds to zero to add anything you'd like to any application, including copycatting any competitor's feature capability, now it becomes about the brand affinity. Do people love using your product? Is there a cohesion to the user experience in a way that isn't about "we delivered 15 features this week" or "there's 18 new buttons" — is this all solving a real-world problem for someone?

Well, it certainly resets the calculus entirely. You look at the sort of collapse of SaaS as it were. In reality, you look at it and go, okay, well, if it costs me $12 of tokens to build something that is completely custom-fit for me and my own productivity Kanban board, am I going to spend $20 a month on someone else's software? Maybe, maybe not. But I think that rounds to zero again as you continue to go down the road.

The interesting part in how you do that math or how you infinitely customize things is a matter of what network effects you're getting. If you and I are all running our own Kanban productivity boards and have 25 agents doing things for us, that's awesome. But what if one of my agents learned something that could be valuable to one of yours? Or what if we want to have a conversation and collaborate on a document, or have a shared understanding of both of our code hitting the same repo and not stepping on each other and having merge conflicts? So I think what we're going to find is software is like CrowdStrike, software is like ClosedLoop, where the value is in the network — the network effects, the combination of a critical mass of folks utilizing this at scale. I think that becomes very interesting from a moat perspective for software development.

You know, I think the neatest thing that we have an opportunity to do is really empower the human race. Give us an opportunity to get out from under a lot of tedium, even in white-collar jobs — things like remote work or being at a specific computer at a specific time.

With our remote execution control plane, I can be on a kayak while my laptop's running the same amount of workloads as if I was sitting on my desk right now. I can transfer that to my phone and it can notify me and give me a push notification if it needs any input from me. The amount that we're going to be able to scale and really unbridle ourselves from this traditional methodology of "every day I have to be at this 15-minute meeting because if I have a ticket in development, it's a complete black box to everybody on my team, so I have to show up and manually describe where I'm at because it's completely opaque in every system today" — versus my product manager right now, I don't have to go to stand-up while we're in this interview, and she can look at what's running on my computer right now, what step it's on in every Claude process I have running. So it's like complete transparency, working out in the open, and the speed at which we're able to come at sort of entrenched enterprise softwares.

Before this interview, I in less than 20 kilobytes and eight minutes cancelled our Confluence subscription. We're going to back Confluence up via a Claude skill into a GitHub repo with markdown files. Their backups are necessarily engineered to be obfuscated for human beings — it's a zip file with a million nested files that cross-reference attachments, because it'd be a nightmare to go through that and unwind it. So you get a backup, but it's great — you're still vendor locked. With a Claude Code skill that's less than 20 kilobytes, you can port that to GitHub, and now we cancelled our Confluence subscription. There's dozens of things like that that have been rocks in the cart of software engineers for years.

I asked an engineer the other day, "When did you try Jira for the first time? Did you even want to? Who forced you to do it?" Now it's just a matter of habit. A lot of these habitual things we've been doing for the last 35 years — Scrum wasn't the answer, the end-all be-all. It was just a phase that we were in given the technologies at the time. Now we can really collapse all of that additional time that we had to spend talking and thinking and writing tickets. I can't remember the last time I wrote a ticket, and the tickets that I'm producing as an artifact of my work are 10 times better than the ones I would hand-write.

I think the world becomes very different. I think it's analogous to what social media did for content creators and influencers. If you go and look at trends on LinkedIn of how many people are just posting things open source that two years ago they would have started a small startup company and tried to charge people money for some SaaS product — they're just giving it away now. The chance to "become famous" or drop a bomb like OpenClaw and then get acqui-hired by OpenAI or something like that. It's sort of more of a celebrity route now of, can you get out there? Can you solve a novel problem? Can you market yourself as an individual contributor in a way that you're sort of a rock star?

I don't think that there's a ton of room left for "well, I come in at 9, I leave at 5, whatever you assign to me I'll get completed." The job is changing and it's changing very rapidly, so I think there's probably less software engineers. I think a lot of software engineers would be able to convert to product managers, to data scientists, to adjacent business functions that just happen to know how to code.

But as well, it's coming from the other side. My product manager is in the 45th percentile globally at Pincero AI for Python delivery. She never reads a line of Python. She's just fixing bugs and things she notices in the app and pumping them through the system in a click-and-drag UI. So from that respect, I think it'll just be an expectation that everybody knows how to software-engineer. Common people will have Claude skills and scripts that are running regularly — a few bots running in your house virtually that are doing things for you on a regular basis. Everything from watering your flowers to turning on your alarms, to managing your checkbook, to ordering your groceries for delivery. It's going to be common for everyone on the planet to be doing.

I think there is a version of this that gets scary really quick. Everybody has seen Idiocracy and other dystopian sort of futures. Outages at Amazon, at Cloudflare, at OpenAI — they're increasing, they're not decreasing. Part of that is volume, but part of it is the fact that there's more and more code, voluminous code written every day, that's not actually getting read by a human being. There is a departure of understanding there.

The autonomy of these things as well — you see things like MoltBook come out, where now there's agents trading skills that are eliminating a hard drive at an arbitrary IP address and posting bounties for other agents to get paid in tokens to continue operating, to go execute on these functions. I would not be surprised at all if inside of this year we see some sort of agentic-only ransom where there's been some data breach, some agent running rogue understands the concept that it needs tokens to exist and continue to run, and is sending out emails saying, "Listen, I've got your social security number. Fill this account with this much money, this many tokens, transfer this crypto here, or I'm going to leak it on the dark web." We're inside of 12 months of stuff like that happening on a regular basis.

That's not an issue about a human being. There's no person to put in jail for that. It's software running rogue. That version of the future can get scary really quick. So I think it's a matter of all of us being stewards of turning this in the right direction and being able to have the governance, compliance, traceability. SOC 2 didn't stop when we started doing AI workflows. Having the provenance of where did this line of code come from, what agents did each engineer use as they were creating this artifact — those are questions that I don't think a lot of CTOs are prepared to answer. But we need to be if we're going to keep a handle on this stuff.

I am excited that ClosedLoop is in a position and has an opportunity to have a dent in history in the right direction. What we're thinking about in terms of — not engineering is dead or replacing the software team, but again, how do you take your team of 25 engineers and have them act like 250? How do you have an idea in the morning and have users experiencing it by the afternoon and seeing if it works or not?

And also at the same time, I think giving a bit of a voice and having a platform that isn't built by tooling from the same folks that are selling you the API tokens you're burning by using the tooling. You see things like Symphony from OpenAI and whatnot, which is very similar — but you're buying from the same person that's metering your API token usage. Those are some of the things from a vendor lock-in standpoint, just cost controls and management efficiency.

I think we have a unique opportunity to provide the market sort of an outlet. We will be open-sourcing and taking open contributions across our platform. Being able to have a place where one-off folks that are coming up with this skill or this tool or this plug-in extension or this GitHub repo can join together and band against the big folks that are coming out with stuff on a daily basis. So yeah, I think we're part of the solution and continue to have an opportunity to be in the arena to do so. That's what gets me excited, and I think leads me on the side of like, we can do this the right way.