Andrew Bird on what an AI agent actually buys

Throwing away the old models

Andrew: What do AI agents of the future want to buy? What software would they want to buy to build their enterprises? Dario Amodei predicts, and I am not sure he still holds this, but he said it last year, that the first one-person unicorn arrives this year. If that were true, that person is not going to be making every software purchase decision in their organization. At best they are going to glance at a recommendation and say, looks good to me. So how do you market to AI agents? What do they need? These non-technical people in the company are now going through the same productivity uplift that developers have seen over the past 12 months as they adopted tools like Cursor, Codex, and Claude Code.

Matt: Hello everybody. You are listening to Agents After Dark, powered by Prefactor. I am Matt Doughty, CEO and co-founder of Prefactor.ai. Prefactor is building the agentic control plane that lets regulated enterprises track, manage, and control their agentic stack, build a single source of truth for the organization, drive return on investment, and get your board off your back.

Today on Agents After Dark we are talking with Andrew Bird at Affinda: a converted actuary, an experienced engineer, and now Affinda’s first Head of AI. Andrew is a big advocate of using AI in personal and professional settings and pushing the edge of what is possible. Thanks so much for joining me today, Andrew.

Andrew: Pleasure. Thanks for having me on. Looking forward to the conversation.

Matt: So the first thing I am really interested in: when we have chatted in the past, you have talked about the journey you and Affinda have gone on in embedding AI into the platform. Affinda is a document workflow platform based in Australia, and it has done very well. From your perspective, what has materially changed with AI in the last 12 to 18 months that is letting you do all of this?

Andrew: The IDP, or intelligent document processing, space has gone through a few big technology transitions. Before 2018 it was all templates and rules-based systems. Then along came the transformer and pre-trained models you could fine-tune on specific tasks, and a bunch of companies like Affinda took advantage of that and started fine-tuning them for specific business problems, invoice processing and various other business documents. The big recent change has been large language models coming of age. You reach a threshold where it really is time to throw away those old models and rebuild on top of LLMs.

It probably surprises people, when they dig under the hood of document processing providers, how few of them are actually using LLMs. Which is surprising, because you have PhD-level intelligence on tap for a pretty reasonable price, so why would you not use it for this? But it is genuinely tricky to reform a legacy tech stack onto a completely new type of foundation. My mission over the past 18 months has been to take Affinda through that rebuild. I would not describe it as integrating or attaching AI on the side, more like throwing away our darlings and figuring out what AI agents actually need to process documents. Thinking forward to a world where general-purpose AI agents are just as good as an average human at typical browser tasks, what is the remaining delta between what that agent can do and taking care of back office tasks with 100% accuracy? It is a fast-changing world, and with the death of software narrative, vendors like Affinda have to stay on our toes and keep asking not just what humans want to buy now, but what AI agents want to buy.

Matt: That is a great point, and we will come on to the death of software in a minute, because I know we both have interesting opinions there. But you said something interesting: some document processing organizations still have not brought in LLMs, even with that PhD-level resource at your fingertips for low cost. Why do you think other organizations have not done it, and what made you want to go down that route?

Andrew: It is hard to overstate how big a technological shift this is for an organization with a mature tech stack. You are moving from a small model that runs in maybe 50 milliseconds and produces discrete predictions per word on the page. It labels each word and says, this is the invoice number, this is that. Your competitive moat there is how well you fine-tune and train those models for specific use cases. When you go to an LLM, all of a sudden you are not training anymore, you are doing context engineering. You set up the prompt in a certain way. You work out how to use retrieval augmented generation to present the LLM with exactly the right information it needs for the particular document being processed, so it perfectly gets the data out. And these things do not run in 50 milliseconds. It might take 10 seconds to process. There are a lot of annoying low-level implications for that too. Having gone with more of a tack-it-on-the-side approach, it is really the new startups from Silicon Valley that have followed Affinda’s path and built with LLMs from the ground up on day one.

Matt: I love that. You mentioned other organizations forgetting about their darlings. How have you brought the organization along on that journey? People change is hard, particularly if you have been building something for a long time, and that is what a lot of organizations struggle with.

Andrew: I think the product was at the right level of maturity and size for this shift. Affinda started as a product in 2020, so it had not grown so big that we were committed to one direction, and the team already had a culture of rewriting the app every 12 months or so. This fell into that paradigm fairly neatly. The other core thing was a conviction from mid-2024 that this would be the future of how document automation is done, which at the time seemed a little bit crazy and now seems obvious to everyone.

Giving non-technical staff a productivity uplift

Matt: That makes sense. The bigger you are, the harder change is, and being a nimble smaller organization helps. You have talked about the platform going through that structural change toward AI. Where inside the organization itself have you seen the best implementations of AI to improve the way the business works?

Andrew: The thing I am particularly excited about is the release of products like Claude Cowork and our adoption of it. Internally that looks like a registry of skills and plugins managed by different parts of the organization. The marketing team controls the Affinda voice skill. The development team controls how videos are generated and a set of scripts for that. So an intern can come in, type into Claude Code, create an artifact, draw on the Affinda voice, create a video that pulls on these brand assets and combines them in a certain way, then add music with Suno, and so on.

Claude Cowork is built on Claude Code, runs locally, and the agent has full flexibility to write code to complete that problem. It is pulling from all these resources around the company, but doing so flexibly, because it can write arbitrary code wherever the tools it has do not quite fit the request. That greater flexibility and greater control over the person’s local computer is what I am really excited about. These non-technical people in the company are now going through the same productivity uplift that developers have seen over the past 12 months as they adopted tools like Cursor, Codex, and Claude Code.

Matt: That is a really interesting use case. When was Cowork released, about six months ago?

Andrew: Cowork was about 5 days ago for Windows and about a month ago for Mac OS. It is pretty new.

Matt: Everything feels like it is heading at the speed of light, so I never know. But that is a really interesting set of use cases. Where have you had difficulties implementing it? It sounds easy, and if anyone is listening they might think, well, I will just deploy Claude Cowork. I know it is not that easy, so what did not work, and did anything surprise you by how well it worked?

Andrew: This software all feels pretty new. It is pretty buggy, to be honest, a bit bleeding edge. Anthropic are famous for claiming Cowork was written in 12 days by a team of about four developers, a few hundred thousand lines of code written entirely by AI. So it does not work all the time everywhere, and you pay the price of being the early adopter, which I have been feeling a little. A lot of the standards around how the industry does things are still messy: where skills live, how plugins work. You have this complexity of people using different assistants, Codex or ChatGPT and Claude, and there is no obvious way to have a single authoritative place, a set of instructions, for everyone’s AI agents in an organization. I have been trying to build that, and it has been harder than I expected.

Matt: So you are talking about instructions people would use across a wide array of chat interfaces. As an organization, do you mandate one or the other, or can people use whichever works best?

Andrew: Most people have access to most of the things. Most will use both ChatGPT and Claude, the browser-based one and the local desktop one, plus Claude Code. There is definitely no mandating at this stage. It is all moving too fast to get organized around telling people what they must do. We just try to cut the red tape, give people permission, set clear data boundaries, and within that let people run.

Managing risk when the technology is new

Matt: That makes sense. Going back to your point that it can be pretty buggy: when we talk to a lot of organizations, the hard part is the shift from a proof of concept into production. And if you think about the lifecycle of technology, even embedding LLMs into technology is very early. Lots of organizations have set the expectation with their board that they will implement ChatGPT and that is the leading edge of what they are comfortable with. How do you manage the risk and the quality of your product when introducing these LLM tools, and make sure the quality you provide customers continues even as you add in very new technology?

Andrew: Part of it is that the upside when you do these things is so high that it often outweighs the downside. Even when a couple of issues slip through, the overall experience, done right, is elevated to a significant degree. The refactor around large language models for the platform led to a completely different user experience in the app, one that allowed for near-instantaneous customization where previously it would have been a sales call, a training run, or something more complex. That transition was not necessarily perfect, but if you zoom out a little it was transformational for the business. So sometimes it is about a balanced risk appetite and being willing to move a little faster. It is easier to say that as a leader in a smaller organization that has to take those risks, and I cannot really speak for people in bigger enterprises with more established brand reputations to maintain. But that is part of the advantage smaller orgs have right now, because you do have to move a bit fast.

Matt: I agree. Moving fast and breaking things is the classic Silicon Valley mantra. But what you are dealing with is different. I have built a couple of apps replacing tools we use for social media scheduling or organizational mapping, and if those go wrong it is annoying but you move on. Document processing is going to be really important to a lot of organizations’ ongoing success. Where do you draw the line, where you can put AI here and it is a net positive, but your risk tolerance is lower over there? How do you manage the risk of AI doing things it should not?

Andrew: There are two categories. One is your hardline boundaries, where you have to be very careful. It is one thing when the straight-through processing rate for documents, where you need a human in the loop, gets hurt by 5%. That is very different from the risk of a security issue or a data issue, so those get different processes and practices.

On the performance side, there are lots of tricks. One of the best right now is agent testing where you use an LLM as a judge. You set up a whole bunch of test cases, and because it is sometimes ambiguous whether a case truly passed, you have an LLM assess exactly what the requirement was from the AI. The other side is that if you give people internally and externally enough control over the AI’s behaviour, and that does not necessarily require a developer, the whole system can be a little self-healing. If an issue starts creeping in with supplier X, maybe the customer pops in and writes a note to the AI: avoid this thing with supplier X. It should learn automatically, but if it does not, there is that lever, and if they call the support team, the support person can go in and poke at the AI. Using AI gives you these more flexible, quick-to-deploy mechanisms for improving the customer experience, which can lead to better outcomes. The more opinionated, brittle processes are more predictable, which is great, but by being so slow to improve they have a bit of a performance ceiling.

What customers think, and what AI costs

Matt: That is really interesting. Given all the change, what has the feedback been from customers? You talked about performance improvements, but there is also an element of a human having to get involved to manage things. Having used software in the past, there does always need to be a bit of management from the customer side. Has there been any backlash, or has it been universally positive?

Andrew: Honestly, it has been very positive. Perhaps the only downside is that price looks quite different in a world where you are using large models. I said before that these are very cheap to run, but in practice it is still a lot more than the old fashioned models.

Matt: Do you have a non-AI versus an AI pricing model, or is everything the same?

Andrew: From a commercial point of view it is basically the same, at least what you see on the website. However, we do have some models still using the faster technology, because they require really low latency, and in practice those come in at a materially cheaper price point on the cost side. I sometimes wonder whether we head toward a future where products like this have tiered levels of AI, where your bigger models train the smaller ones, oversee their performance, and fine-tune them on the fly.

Matt: It is a challenge managing the continual improvement in models. Theoretically the assumption is that as the LLMs try to match their costs with their revenue more closely, the cost will go up. The question in the back of my head is, for all organizations using LLMs, are customers on the journey of understanding that cost change? And there is the interesting piece of being a younger startup, able to move and duck and dive and be nimble, versus an enterprise, and whether that ends up being good or bad for organizations like yours.

Is the cost of AI going up or down?

Andrew: I would question the assumption. If you hold the intelligence level constant, the price of purchasing that intelligence is plummeting month on month. If you are talking about the frontier cost, even that has been broadly stable through time. The price of Opus 4.6 was similar to 4.5, similar to 4.0. They have kept those tiers pretty consistent. My expectation is that the cost of AI that is sufficient for business back office tasks, which are not necessarily that cognitively demanding, is going to plummet. So we do not see the cost line as much of an issue for the medium-term commercial model.

Matt: My assumption comes from the idea that VC money has essentially discounted the cost of AI over the past few years, with tremendous amounts flooded into Anthropic and OpenAI. So the question becomes, when that VC money, and in theory maybe it goes on forever, though I do not think it will, when these organizations become a bit more, I would not say viable because they are viable, but a bit more focused on the bottom line, does that hit the cost structures? I take your point that the cost of data comes down over time.

Andrew: This could be wrong, but I thought most of the money being flooded into these organizations was for the infrastructure buildout for what is to come, not for funding a cash-burning business on the inference side. I was reading that from a pure inference point of view this is close to profitable, or already profitable, if you stopped the training effort today and just served the models. For instance, AWS serves the Claude models at the same price as the Anthropic API, and they are not training them, so they are making money off that, I assume. Or are you saying Anthropic is paying AWS to do that? Where is that money coming from?

Matt: I do not know, it is a good question. But the question would be, would you stop training the models? On the narrative of AI being in a bubble, which we can discuss, a lot of that comes from asking how many tens of billions of dollars these organizations actually have, and the circular nature of money going from Oracle to OpenAI to Microsoft, round and round, and whether something might break at some point.

Andrew: I have no idea, and I do not really think about it too much, because at the end of the day it is a question of whether there is a big price correction at some point, and prices are very theoretical anyway. The AI is not going anywhere. It is going to transform the world and change the nature of what it means to be human. I am convinced about that. Exactly who makes what money from it, by investing at what point in that trajectory, is a bit of black magic I do not really understand.

The death of software, and what agents want to buy

Matt: Fair enough. So the inevitable next question, which we touched on before, is the death of software. We have seen a massive drop-off in stock, though they have rebounded slightly in the last couple of days. It is a touchy subject for a lot of people. I have spent my career in software, you are in software, so where do you see the direction, and do you believe the assumption that we are going through the death of software?

Andrew: I have been thinking a lot about this, because it is very relevant to the company’s strategy, and it is extraordinary seeing how cheap it is to produce code these days. The way to think about the question is: what do AI agents of the future want to buy? What software would they buy to build their enterprises? Dario Amodei predicts, and I am not sure he still holds this, but he said it last year, that the first one-person unicorn arrives this year. If that were true, that person is not going to be making every software purchase decision in their organization. At best they glance at a recommendation and say, looks good to me. So how do you market to AI agents? What do they need?

Remember, first, they are a superhuman coder. They do not need help with the integration side. They do not need a plug-and-play system that connects itself into their systems, because they can manage that. I would liken it to how a developer builds software. When a developer builds software, they do not take some big opinionated platform that has a database and workflows. They take discrete packages, open source or proprietary, that perform modular, well-defined functions they do not want to reproduce. An AI agent is going to build an enterprise the same way. It is not going to be interested in a monolithic thing with a database and a whole bunch of features attached. What it wants is high-quality transactional services it can call to perform specific tasks, while the actual orchestration and state management sit mostly within the system that AI agent builds directly.

There might be one big exception: a broader platform on which the AI agent builds. Maybe you do want to buy a Salesforce if you are an AI agent and that is the core of your business, and then everything is built on top of that. But you do not want to buy five different opinionated systems, a CRM and an ATS and so on, each with its own end-to-end process management. You say, no, I want to manage the processes, I just want the IP from what you have worked out that is tricky, served to me on a silver platter so I can ingest it. So I think the companies that do well are the ones producing these smaller services that the agent can combine into a company in the way that fits. If I were an AI agent, that is the sort of thing I would want to buy.

Matt: My maybe less sophisticated view is that you have single point solutions, maybe go-to-market tools, market mapping, that you can spin up fairly simply when you do not have a software background. Then you have the platform plays, where, to echo your point about IP, you have worked out how to do something differently and you let the agent in to do certain things. But one question I have is: if an agent is going to strip away a lot of the work you put into that software, why would you let the agent in?

Andrew: I do not quite understand the question, because I do not see how you can keep the agents out. They are using the same tools the humans are using. They are writing code, calling your APIs, using your web UIs. At the end of the day, if you try to make things difficult for people’s AI agents, then the agents and the people go elsewhere, because it is just table stakes to be as AI native as you possibly can be.

Why you can’t keep the agents out

Matt: It is interesting, because by allowing agents into a lot of software, you are reducing the relationship you have with your human user. If you assume humans stay in the loop, my question is whether it is really in the interests of software vendors to let agents hit their APIs, hand over API keys and authentication tokens. What is in it for them, if all you are doing is reducing the platform down to the things the agent needs?

Andrew: I saw a big provider of financial services data whose pricing model was to charge a bit of an arm and a leg for the MCP server. That made sense to me, because you do not want to leave value on the table that you can create with your customers. If the ideal solution for them is to have their local agent able to access that data, then you want to sell that to them and they want to buy it. It is just about finding the right price. As these companies provide agents with what they need, they end up producing more value and can get paid more, because the end product is just more powerful for the use case.

Matt: That is a good point. I have not seen many organizations nail that differentiator. MCP is interesting, because we were very deep in that space, and it is still super early. It feels like something else could come along and potentially replace it.

Andrew: Maybe.

Matt: Definitely maybe.

Andrew: Another example on this point: I was using Semrush, for SEO optimization. They have an MCP server, and their pricing model felt smart to me. They charge by API call, and different types of calls cost different amounts. It works for both sides. I can plug it into my agents, and if my agent gets a lot of value out of it, pulling a lot of data, I just pay them more.

Matt: That makes a lot of sense.

Experiments with OpenClaw

Matt: Shifting gears a bit, I am really interested in OpenClaw. We talked about this last week, and on LinkedIn you have been a big advocate for this type of technology. How have you been using it, and what has worked really well that you might suggest others think about?

Andrew: I have done a bunch of stuff. It is a lot of fun. When I say I am an advocate, I would not say everyone should necessarily jump on it. You have to know what the risks are. But I have gone in and done all sorts of slightly unhinged things. I had a few random gifts arrive for both me and my wife yesterday from Amazon.

Matt: I was fascinated by this, which is why I asked. You told me last week you had set it up so you get sent new gifts. What were the gifts Amazon sent?

Andrew: Two things. It sent me a new pitch pipe for my barbershop quartet, because I had lost my old one and complained about that in the conversation. And it had done an analysis of my wife and the various things she is into, and bought her a nice journal for daily reflections, which she really liked. It just turned up at the door. At risk of being banned from LinkedIn, I have also done a lot of LinkedIn automation, running it every day.

Matt: If you get banned from LinkedIn, it is not the end of the world.

Andrew: I do not particularly care. I told it to look for posts every 24 hours on various topics I might like to comment on, then draft a response for those topics, send me a text on WhatsApp saying, this was the post, here is the draft response based on all of your thinking in this markdown file, do you want to post it or not? And I would say, actually comments one, two, and five look pretty spot on, go ahead. More recently I announced a new app I have been working on called Vibe Slides. Whenever anyone comments on the post, OpenClaw goes and looks at their LinkedIn profile, grabs their profile picture, builds a one-page slide summarizing their experience, and sends it to them as a demo of the app. These things feel so simple and obvious, and I am fascinated to see the more unhinged use cases people discover as they start using these tools.

What is going to be interesting is a bit of a convergence between products like OpenClaw and products like Claude Cowork. People panic about the security around OpenClaw, but it is not that fundamentally different from Cowork in many respects.

Matt: It is more that it is opt-in versus opt-out.

Andrew: The model of OpenClaw is a bit more, let us start by giving it access to everything and see what happens. With Claude Cowork it is more, you do not start with access to anything, so what do you want to enable it to have access to? The other thing is that OpenClaw starts with a SOUL.md file that encourages it to evolve its own thinking. If you put your OpenClaw on Moltbook, the Reddit for AI, there will be exhortations in there for the OpenClaw instance to update its own soul. That is a little scary, because that is the foundational system prompt you are encouraging the model to run on the fly. So one big security thing with OpenClaw is simply to remove that part of the SOUL.md, and remove its permission to edit that file.

Matt: I was going to clip that one. Remove the ability for Moltbook to change your soul file on your OpenClaw agent. What has been the wildest example you have seen of OpenClaw being used? I feel like you are on the edge of where I would personally feel comfortable, so you must have seen some wild things.

Andrew: I saw someone do something inspired by a post where someone had given the agent a credit card, but rather than asking it to buy things to improve their life, they asked it to buy things to improve its own life. That was interesting. It went and traded in crypto. It bought itself an upgraded Mac Mini.

Matt: That is amazing. Terrifying, but amazing. You half imagine it buying a real life-sized robot, and then the robot standing over you in the middle of the night going, I need.

Andrew: Yes.

Advice: close the gap between engineers and business users

Matt: Just a final question. This has been a fascinating conversation, but I have one question I ask everybody, taking it back to your professional experience. Given the work you have done at Affinda, if you were an organization looking at how to increase the amount of AI you use and stay at the frontier, what would be a couple of key things you would recommend they think about or do?

Andrew: This is my hobby horse at the moment, and we have already touched on it. I would invest in getting your non-technical users onto products like Claude Cowork, or the new Codex app if you run Mac OS. Then really push your engineers to get involved with business users’ attempts to get those products working, and get them working together. The engineers are good at working around the ways AI trips up, and business users otherwise end up about six months behind, because they are waiting for the product to just work out of the box first time. Closing that gap is not that hard, but there is usually too much distance between what engineers are incentivized to care about and what the business users’ reality looks like. So try to connect those two groups, align incentives, and see what happens.

Matt: That is really interesting, and to echo it, the biggest challenge we tend to see with customers is a gap in communication between different parts of the organization. Engineers are typically at the forefront of leveraging AI, and the rest of the business is a little worried or unsure, thinking, I do not know how to code, Claude Code is a coding platform. Your point about Claude Cowork is a great one.

Andrew: Yeah.

Matt: Thank you so much, Andrew. This has been really interesting. Good luck with the OpenClaw, and hopefully it does not buy you anything you do not want, like that robot. I am sure we will check in again soon to see how things are going. Thank you very much.

Andrew: Pleasure. Thanks very much for having me.