About this talk
In this session, Jamie Demora, CTO for startups and digital natives at Microsoft, discusses the shift towards agentic software, which operates autonomously based on user goals and reasoning. He emphasizes the need for CTOs to adapt to this new reality by rethinking the architecture, design, and metrics of software products. The talk covers the evolution of software over the last 30 years, highlighting how agentic companies are reshaping the tech landscape and compressing timelines for development and funding. Through real-world examples, Demora illustrates best practices for infusing agentic capabilities into existing SaaS products, emphasizing the importance of data interoperability, semantic layers, and outcome-based metrics for measuring success. He concludes by urging CTOs to consider how they can leverage their existing complexities as competitive advantages in the rapidly changing software environment.
Full transcript
And next up, let's get to our next session for this morning before we head to our coffee break. So Jamie Demora is CTO for startups and digital natives at Microsoft AMIA. He's going to take us into the agentic era and continue this conversation. Software that doesn't wait for users input. Um software that understands goals, reasons, and acts. It's already here. It's not coming. So this session is
about what CTO's need to do right now to prepare. Jamie, >> thank you very much. Well, good morning everyone. Uh my name is Jamie and I lead the CTO practice at Microsoft for the startups and the uh unicorns division. So I'm fortunate enough to actually work with the most disruptive and innovative companies across Europe, Middle East and Africa. And in the last three years, it's all been
about either infusing AI to traditional SAS companies or to actually scale help scale uh AI and uh agentic native ones. So that's what I'm going to be covering today. What are the best practices that I see and also how software itself is actually being reinvented and we need to think about it differently. how we architect it, how we design it, and how we even measure it. So,
what we're going to be covering today, five sections. First of all, it's the neogentic reality and why the economics have actually and dramatically changed. Then, we're going to go from a bit of a history tour through the evolution of software in the last 30 years. Then we're actually going to be covering the agentic stack and I'm going to be using three specific customer real stories that I'm
going to walk you through and how their architecture actually looks like. Then what are the steps that you can take if you have a traditional SAS product in order to actually infuse not just AI but agentic capabilities. And we're going to finish again with some best practices and takeaways that hopefully will help you again to move forward your agentic practice or um development in your product. Just
want to mention that I'm I'm actually in two months uh I'm co-authoring this book about building agentic applications on Ashure and many of the learnings as well that came from that book and coming uh from my customers are going to be um position in this talk. So I'm going to start actually with this dashboard the lean AI uh leaderboard. Has anyone seen it before? Good. Just one
person two. Good. So basically what it does it ranks the most capital efficient companies capital efficiency right now is the number one metric that VCs and the market are looking for and there's a clear trend if we talk take out telegram which we know is an outlier most of the companies in this leaderboard are actually agentic by and that's not a coincidence it's just the evidence that
right now Agentic companies are becoming the new operating model for high performance uh technical or tech companies and that's also compressing the time frame for software. So there's this new mantra in Silicon Valley that talks about the two-year startup. So before it took us between five to seven years to actually get to an exit. Now we see how again times are compressing. We see companies in three
months building out of subsidized compute and off-the-shelf models, building really great products and raising amazing rounds of funding. We see how actually they build a modes already through data and through um interoperability and custom logic already in months 3 to six and then already by month 24 there's a consolidation in the market. We've never seen this before in the world of software and what this means is
that's just the pace and the velocity is changing and we need to adapt to this new reality. So this is how I see right now the software landscape very quickly model builders basically you can think about the mistral the open of the world stability.ai all of them are actually becoming right now as well agentic companies think about the dream studio from stability.ai AI, the agentic platform from
OpenAI or think about eventually the ones from 11 Labs as well that are getting more into agents. Then you have the native agentic companies and all of them are extremely fast. They're building on top of state-of-the-art models and their mode and their value lies mostly again on the application layer. But then you have the traditional SAS and those are the ones that are trying to not just
again infuse AI to their product but again to become a companies but they're struggling in many ways either they or struggling again from a technological standpoint or also they cannot really define the ROI in a clear way but the truth is that every company right now wants to become an agentic company. So we've come a long way from software that actually um was very heavy on clicks
software in which actually the reasoning came from the user that's tried to navigate and make their way through highly complex UIs and dashboards and it was all about the clicks. So think about all the potential automation that we can actually achieve right now through agents. It is true that most companies right now have already embedded AI to an extent to their products and what that means is
that they're doing already probably retrieval augmented generation. So if you look at this example, yes, the agent already search makes some semantic search through a database performs the answer to the user but then it tells him hey you now need to open a ticket. So that's not full autonomy that's just assistance. But now what we're going through is again full autonomy and that happens because of many
reasons but mostly because of three. The first one is that LLMs and agents are extremely good at understanding and structured data. You can just get a structured JSON out of any prompt or any query to a database. You also have very strong tool robustness. Right now you don't have need to have a perfect UI. Agents can actually navigate and even they can afford and this is the
third point as well. they can uh face novel cases. That is something that they could not do before. You don't need to actually prepare for every edge case. Agents can actually reason and behave and adapt according to the context. So zooming out for 30 seconds, this is actually the evolution that we've seen in just the last let's say five years. We've seen again how the operator before
it was the user. he or she was the one actually providing and trying again to navigate that software. then it was AI assisted uh software and now the operator we see that it's not actually the humans in many cases the operators of software or being agents and that's again how we've come from a world in which humans needed to adapt to highly complex and sometimes even clunky
software to right now software that fully adapts to humans preferences and needs. And what this means is that also we're making significant changes to the to our product architectures. Right now SAS was optimized around user sessions and user runs, but now everything is around actually outcomes and long lived uh executions actually that start with intent and end with verifiable outcomes. That's something that SAS had a hard
time actually accomplishing. The second one is that the unit right now of measure is a run. We need to ensure that our agents can actually perform actions uh on our behalf. They actually can decide what actions to take. And it's not just about stateless APIs anymore. Is about context management is about um ensuring that the agent performs the right or takes the right step and action on
every step of the way. Another big change is again on the data layer. Agents are not good at reasoning over tables and rows and tickets and logs. We need to build a semantic layer. That's something we cover later as well. And then last but not least, normally we don't see that much anymore traditional uh companies uh following traditional QA. Now evaluation actually starts at this at the
very beginning and it be it actually becomes like a gating function So if we go and look at the architecture and how does an agentic architecture look like the first thing I'll mention is that companies don't need and this is something that I talked to a lot to a lot of CTO's companies don't need to actually throw away all their SAS or they don't need to rearchitect
their ex existing SAS they need to think how to build on top of it okay and if you think about just the user experience yes before it was all about navigation now it's more about user intent and assistance and Yes, now it's about not just text and uh forms, it's actually about video uh images, text or voice. Um but the core change right now and as you
can see the agentic orchestration service on top of the application platform is that that orchestration service is the one is the brains of the uh of the software. In the same way that before it was actually the human providing the reasoning now is that orchestration service and it's important I will just talk about three main layers. First one is the policy and the policy is that enforcement
layer that decides what can the agent do when and actually when does the human need to make a decision. Then you have the memory that is actually what keeps everything together provides the full context across different threads and sessions to ensure that the user the agent provides the right response or performs the right action. And then last one is the tool calling and code execution environment. That's
what when that's the execution layer right now that is actually evolving into skills which we'll see in a second but that's also one of the most important ones. Just want to mention as well external systems interperability is a key component right now in aentic systems. If your agents cannot operate with other tools or other agents probably you're losing distribution. So that's the stack and now I want
to drill down into four core pillars that actually are making it or breaking it for most SAS companies. The first one is the data layer. So most companies strategists point their agents to their traditional databases and as mentioned before uh agents are not really good at reasoning over to uh tables or rows. You need to actually expose them again to a semantic layer. They're not good at
just uh a SAS eventually you would uh query a database but agents need again for example to understand the difference between a customer entity in Salesforce and an account in Sendesk and it might be the same. So you need to think about first of all how to actually connect all the different data sources you have whether that's on slack on notion on shareepoint on many other multiple
disparate data sources you then need to unify them by domain what that means is that you don't want your agents pointing to 14 different tables but you want to create an entire canonical view that your agents can actually reason over and then eventually yes you have the semantic layer as where you will have not only embedded. Embeddings is one step but eventually you want to create your
own vector index. You want to create as well your own ontology. You want to eventually also reindex and provide the freshness to the data so the agent can constantly query that uh or uh retrieve the right information. The second one is interoperability because as I mentioned before you definitely want your agents one to be able to I mean uh for them to be consumed by thirdparty uh
systems and second you want them as well to consume those third party systems or communicate and interact with agents and on that regard that's I mean protocols like MCP or A2A are actually really important they reduce the cost of integration and they make these ecosystems possible. The third one is skills. And let me maybe just explain why right now they're like the hot hottest thing in the
last three months. And that's just because they're way beyond what we thought about uh tool calling or eventually some people even call it like an advanced API and it's way more. I like to see it as an ex executional capability with operational guarantees. So in the skills yes you do call to different tools and you perform you allow the agent to perform different tasks but also you
per you provide the interface contract what are the inputs and outputs on those skills you provide as well the policy and the permissions for the agents to perform those actions in a safe way. You even provide the operational envelope the documentation. So at the end they encapsulate as you can see if we think about a product marketer they encapsulate everything that a product marketer could do if
we think about market research. So for a marketer uh to perform market research as a skill you would need eventually to look for information on the internet to actually retrieve data from different knowledge bases create content. There are multiple things that you would do but you want to define again how does the agent perform those actions. And the last one is something that is killing a lot
of SAS companies which is how they measure success. So SAS again mostly tracked human uh human interactions in their software. So it was mostly around daily active users time in application and that is totally changing right now. It's actually around work completed. If you think about an agent like intercom's fin, it doesn't measure how many tickets does it actually support a human. It measures tickets completed or
to resolution and it actually charges based on that. So, we're not going to get into outcome based pricing, which is probably the next big thing in software, but it actually it's about measuring things like task completion, times of resolution, cost per task as well because that's going to define the unique economics of your software. So, we need to change the scorecard. Interestingly enough, the thing is the
better the metrics on the left hand side, the worse the ones on the right hand side. So you might even think that you're getting churn because you uh your your software is not getting used as much but that means that the end customer is getting more value with that one of the things that eventually companies can start doing today to design for SAS products and I'm going
to try to specified in a concrete workflow let's say a customer on boarding agent okay that takes care of the entire workflow because that improves identity data approvals, connections with external systems. The first one is that agents fail when the job is ambiguous. So let's be sure that you actually define very well what the agent needs to do and you define as well very clear success metrics.
It's important as well to define the autonomy boundary. You want to be sure again what the agent can do versus when does the human need to actually get into the loop. You need to also be able to configure that autonomy and boundary by tenant, by role, and even sometimes by risk appetite. It's not the same if you're working with enterprise customers or SMBs. That really depends. Then
the second one is that agents actually fail when when execution is unsafe. So if you're thinking about this on boarding agents, it will want to provision IT resources, open email addresses. you don't want to expose your production environments to that right or your production database for that. So it's important again to really contain and ensure what can the agent uh access. That's why exposing capabilities of your
software via tools or APIs is going to really also create guard rails for that agent to execute on. And one very important thing to to say is like never rely on the model itself for security. Okay, it's important again to think about network uh network boundaries, identity, permissions, all of those need to actually be configured when you think about agent agentic systems. Then the third one is
design for semantic retrieval as mentioned creating uh or I mean creating embeddings or having embeddings of a specific tables or databases in your system. That's a good first step but you need to think as well how can you actually create canonical views on top of your data how you can actually link entities how can you actually verticalize by domain so agents can reason over that data. And
last but not least is how you actually do how do you put everything into production. And that's again by adding an entire orchestration layer because these agentic workflows eventually are going to take 20 30 40 50 steps and you want to be sure that if something fails on step 27 the task is not doesn't fail immediately. You have a retry logic already built into the system. you
can actually if there's no availability of a specific model you actually have a fallback model as well and that you have full traceability of what is the agent doing at every step of the way. So also traceability and observability are absolutely crucial when you build that execution uh or sorry that orchestration layer. So with that, let me just walk you quickly because I'm running out of time
on three customer um or three real world scenarios of customer of of companies SAS all SAS unicorns from Europe that have successfully moved to Agentic. The first one is Factorial. They're a business management solution 130 million in revenue growing extremely 80% year-over-year. And what they basically did they created this uh solution called factorial one and it actually acts on behalf of the user both on HR functions
IT and business management and processes. Three things I want everyone to look at. The first one is when we talk about interoperability as you can see factorial is actually being consumed sorry one is being consumed from different systems or interfaces because they don't care about what the interface is they care about their capabilities and skills being consumed. So you can actually access it from the factorial website
it could be through M365 copilot could be via teams or even right now they're opening it through WhatsApp. Second thing to mention is actually the orchestration layer. They use Mastra and Azure Foundry for that. And what they have done on that orchestration layer aside from actually and that's a simplified view aside from defining the entire logic is they have exposed every department has has actually exposed their
skills so they can be consumed again by their agents. And then third is the fact that their SAS still is exposed as an API that the agent can uh consume. So that's something really important. Next one it's contract port AI contract life cycle management software uh one of the leading players globally and they have full they have gone full into agentic AI to the extent that have
they have rebranded themselves into LEA and three things I want to mention as well here the first one is that if you think about legal work it's inherently cross system so they have actually because contracts live everywhere right they live in ERPs CRM so they have actually made um they have met made a big pillar or foundation of their entire agentic system. The second one is and
you can see it here on the box is how actually they have exposed all their agent capabilities as skills as well. Whether that's contract creation, contract management, payables and receivables all of them all of them are exposed as skills. And the third one is unified semantics because also uh legal work is is uh language heavy work and you need to be sure that you actually have access
to the right information. So they have actually created their own ontology and semantic layer for the agents to reason over. The last one is backbase. It's a global fintech company uh that provides a digital banking platform for banks uh over the world. they also have gone full in to aentic and here at least one I want to show you is I mean first you see here the
entire uh stack but important things to mention and I will just mention two for the sake of time the first one is on the agent orchestration and it's fully decoupled from the rest they're using lchain in this case and that's again where the entire runtime and logic actually happens but then they have decoupled every component I think it's interesting as well to look at the inter interchangeability
of the models. They use OpenAI models, they use anthropic models, they have their own models as well that they have used and the system runs exactly the same regardless of the models they're using. So with that just key takeaways. The first one is again start with one workflow end to end one highv value process whether that's sticker resolution compliance check but start with one process and instrument
it heavily. The se second one is turn your product into skills. Try it to make it operable operable by agents and thirdarty systems. The third one is build evaluation before autonomy evaluation and creating your own evaluation pipeline. It's absolutely crucial whether you want to create your own evaluation uh uh pipeline or you want to eventually leverage existing frameworks and use other models as a judge. That's extremely
important and also make it part of your CI/CD pipelines. Fourth one, make your data agent ready. We covered that already. But the fifth one is design for outcomes not usage. So if your product reduces time in app that might actually be a good outcome and not a bad result for your SAS. One final thought I want to finish with because I had the entire talk ready like
a month ago but then open clock came out and software the world of software absolutely changed. So we've been talking about agents being the operators of software. Uh we've been talking about as well SAS interfaces changing uh to adapt to this new trend. But your exist existing SAS might actually hold way more value than you think. I wouldn't rush companies to just throw away their entire business
logic or at least put it into an agents.mmd and into a long system prompt. just wait because things are moving so fast and especially we see how AI agents are evolving so rapidly that with products like open claw for example we've seen how they can operate highly complex task directly and they can navigate a 200step workflow without any problem and that's again why you should think that
you might not want to rebuild everything from scratch especially those highly complex complex workflows and business logic. So there are actually two paths to defensibility here. One is that you can expose your product capabilities as agent consumable skills. That's one. But then second is that your own product's complexity might become the moat itself and the differentiation because reproducing that entire complexity from scratch is going to be
extremely hard in an agentic world. So in any case, your product logic is going to become the advantage. So just to finish, I think that the strategic question is like do you want to expose your platform and your sorry your your product again to other agent platforms to consume or do you eventually want to become the agent platform of your domain? I think that's the question that
many CTOs and CPOs are asking themselves right now. And with that, I just want to thank you for your time. I don't know if we have time for questions, but it's been a pleasure being with all of you here today. Thank
More from this event
See all 36 talks →
Inside CTO Craft London’s tech scene. ⚙️✨#CTOCraft #TechLeadership #cto #techevents
0:28
CTO by title, yogi by unexpected conference agenda. 💻🧘✌️
0:06
A great engineering culture requires…
0:31
CTOs reveal the toughest part of scaling tech teams (it’s not what you think). #techleadership #cto
0:49