- Complex AI agents struggle with long-running tasks and standard chat interfaces due to issues with context retention and limited control.
- Effective human-agent collaboration for complex work requires specialized, high-bandwidth interfaces beyond chat to improve trust and control.
- Agents should be designed with mechanisms like task decomposition, guardrails, and elicitation to allow humans to instill judgment and verify work at critical junctures.
Agents need more than a chat - Jacob Lauritzen, CTO Legora
- Planning and reviewing work are new bottlenecks: While AI makes doing the work cheap, the time spent planning requirements and reviewing outputs is becoming the most time-consuming part of complex tasks.
- Apply the Verifiers Rule: Tasks that are solvable and easy to verify are ideal for AI agents. For difficult-to-verify tasks, focus on human-agent collaboration.
- Increase trust through verifiable proxies and decomposition: If direct verification is hard (e.g., legal contracts), find proxies (e.g., similarity to "golden contracts"). Break down complex tasks into smaller, verifiable sub-tasks, leaving critical decisions to humans.
- Implement guardrails: Limit an agent's actions (e.g., "only edit these three files," "only search these websites") to increase trust and prevent unexpected behavior.
- Improve control with skills and elicitation: Encode human judgment directly into "skills" for specific sub-tasks to handle contingencies. For unknown situations, agents should "elicit" information by asking the user, ideally logging decisions for later review rather than blocking.
- Avoid chat for complex agent interaction: Chat is a low-bandwidth, one-dimensional interface that collapses a complex "work tree" into a linear sequence, making it inefficient for imposing judgment or understanding agent actions.
- Utilize high-bandwidth artifacts: Agents and humans should collaborate within persistent, industry-specific interfaces (e.g., interactive documents, specialized review tools) that allow for richer interaction, contextual feedback, and selective intervention.
vertical AI — AI solutions tailored for a specific industry or domain (e.g., legal, finance).
complex agent — An AI system designed to perform multi-step, long-running tasks, often involving sub-agents, web searches, and file operations.
context-wide state — The full set of information and memory an AI agent maintains about a task, which can be lost due to context window limitations.
Verifiers rule — A principle stating that if a task is solvable and easy to verify, AI will solve it (coined by Jason Warner).
proxies for verification — Indirect methods or metrics used to evaluate the quality or correctness of an agent's output when direct verification is difficult.
decompose tasks — Breaking down a large, complex task into smaller, more manageable sub-tasks.
guardrails — Constraints or rules that limit an agent's actions or scope, ensuring it operates within defined boundaries.
elicitation — The process by which an AI agent asks a human user for clarification or guidance when it encounters uncertainty or needs human judgment.
decision log — A record of decisions made by an AI agent, especially when operating autonomously or making assumptions.
high-bandwidth artifacts — Specialized, often visual or interactive, interfaces or documents that allow for rich, persistent collaboration between humans and AI, unlike linear chat.
DAC — Directed Acyclic Graph, a common data structure used to model complex workflows or task dependencies, often used in the context of agents.
How's everyone doing? Still good? Great. It's 5 p.m. on a Friday. There's just me and two more people behind you and Friday beer, so I'll try to be a little bit quick here. I'm here to talk to you guys today about vertical AI and complex agents and why I think they need more than just the chat. If you've ever worked with a long-running complex agent, you've probably tried something like this. Sorry, that is all white. I can see the flashbang in your guest face. You tell it's research something. You draft a contract, make no mistakes, and it starts thinking. It starts reading. Launches a bunch of sub-agents. Does web search, writes files. Launches more sub-agents. Does more reading. writes more files. Keeps going. Takes forever after 30 minutes. It gives you your contract. You take a look. Plus three doesn't look right. Did you make a mistake here? Did you look at another document? You're absolutely right. Then you see this. Compaction. That's when you know you can give up. It's going to forget everything. It's in the context-wide state. Anyway, it continues. It keeps on going. And you're going to do a contract. Does it look, was it only close three that was changed? Probably not. And so you're going to end up in this state. Not the greatest experience. My name's Jacob. I'm the CTO of LaGora. We are a collaborative AI workspace for law firms. So we're a vertical AI company. We have more than 1,000 customers, more than 50 markets. We've raised a bunch of money. We're growing extremely fast. I'm being told maybe the fastest in history. We are also hiring engineers in London. So in case anyone's interested and wants to be on this growth journey, please talk to me after my talk. Our goal and the goal of most vertical AI companies is to make agents complete more and more complex work in TwinD. That's sort of doing that has changed a lot in the past six to 12 months because there are new economics of production. So it used to be, if you wanted to complete end-to-end work, that you would be focused on doing the work. That would be sort of the main thing is actually just getting it done. But today, things look a little bit different. Because right now, planning work and reviewing work is the new bottleneck. So doing the actual work is extremely cheap. It's very easy to do. But now you have to spend time planning. You have to get the non-functional requirements. You have to get the specs. And you have to spend a lot of time reviewing the work. And if anyone's reviewed big PROS on GitHub, it really sucks. It's extremely painful. Maybe if you're a super AI-pilled, you just get your AI agents to review their own work, no humans involved. Maybe it works. Maybe it doesn't. And when we think about completing complex work, both the planning stage, the doing stage and the rearing stage, the Verifiers rule is a good way to think about work. So Verifiers rule is a term that was coined by Jason, which states that if it's a task is solvable and it's easy to verify, then it's going to get solved by AI. He was primarily talking about foundational models. So if you can make something very easy to verify, then you can do RL environments. You can post-trained. It's going to solve it. I think it also goes for agents. If you can make a task verifiable, you can just run an agent in a loop until it, hey, you did this wrong. Please fix it. And it'll eventually get there. Different industries on different places in this spectrum. It's a little bit more complex than just this, because verticals have tasks that are different places on this spectrum. So if you take legal, we can check definitions in a contract. Super easy. It's a verify. Super easy to get done. Right in contract, it's very easy to solve, but actually it's doing the difficult to verify. Because if you think about it, when you write a contract, the only time you can actually verify the language you use works if it goes to court. And a judge basically verifies it. Tell us if it's good or not. So that's actually quite complex. Litigation strategy is also basically impossible to verify. If you don't know what litigation is, it's when you sue someone or someone suits you. I know we're in Europe now, but the Americans really love doing this all the time. But essentially, if you ask five lawyers, what should be the right strategy for this litigation case? They're going to give you different answers. And so there's no objective truth, which means it's basically impossible. To verify, it's really difficult for AI to solve. Similarly on coding, some parts are really easy, building a successful consumer app. Very difficult to verify. So when we think about this, we think about how to involve humans where it really matters and let agents do the work that we can let them do. There's two things that are important to think about with agent-suman collaboration. Control is the first one. Control is how effectively can a human instill their knowledge into the work that the agent is doing. So how effectively can I steer it? Control is a matter of how much do we need to review. So if I have very low control, I'm going to look at every single agent trace and see exactly what it did. If I have a very low trust, if I have very high trust, I won't look at it at all. Depending on where the task falls in the chart, different things are important. How to increase trust? So if you want to increase trust, there's a few different things you can do. Firstly, you can bring a task down in the spectrum. So here's an example from coding. If you want to implement a feature, well, you can give it browser access. You can do a test or event development. Then suddenly, it's actually a verifiable task, and it's going to do much better. There are similar things you can do in finance and in legal. You can do some things similar as well. We don't have, let's take the contract example in legal. You can't really verify it, but you can look for a proxy for verification. So for contracts, what you can do is you can take a look at previous contracts. These are our golden contracts. We know they work well. Let's set up a test. Is it the new contract? Is it similar to the old one? That's a proxy for verification. That's going to allow your agent to do much better job. You can also decompose tasks. So here's the example with writing a contract. I can turn that from one task into a bunch of other tasks. And I can leave picking a rich profile, picking the precedent document, the negotiation stands. I can leave that to the human. But I can try to get other stuff down where it's easy to verify. So apply formatting. Make it look like all my other contracts. Apply checking definition, which is essentially the whole definition used, or all the definitions that are used to define. This kind of stuff you can build, and then the agent can basically rip much better. You can also add godrails. And godrails is essentially the way to interest by limiting what the agent can do. So instead of being able to do all of this, you're just going to say you can only do these. You can only edit these three files. You can only read these from this directory. You can only search these websites by limiting what it can do. You basically get more trust. Because you know that I won't do all these weird things. An example of this, probably all known on this one, load code. If there's very low trust, it's going to basically tell you every single time it wants to do anything, which makes it extremely useless. And on the high trust end of the spectrum, you just do all the mode it, let it rip, and hope that it doesn't delete your prod database. Then there's control. So how do we increase control? Well, if you think about complex agent work, you can kind of think about it as a tree of work, as a DAC essentially. So here's an example where I wanted to write a report on a bunch of employment contracts. So the agent's going to say, OK, let me research the organization first. Then I want to review the contracts. And I'm going to review for a few different things for each of the contracts. And then I'm going to draft a report at the end. This is extremely low control. Because essentially, I can only impose my judgment at the root level. So it's going to do all of this work, and then it's going to get back to me. And then I can try to talk to you again. And there was just basically the example I gave at the beginning. So very low control. Then there's planning. Planning essentially allows you to steer the agent up front and align one of the approach. And so with planning here, it might say, OK, you should absolutely take these steps. These are correct. These are the closest you should be looking for. This is what you want to review. So this is a good step. It gives you a bit more control. It's easier to impose what you want it to do. The problem is planning. You basically have to do all the work to just know what to do. I'm sure people have tried this in float code. You basically have to go through the entire thing. It's really inefficient. It takes a long time and asks you a bunch of questions. And in the end, it's basically impossible for it to really know if it has all the information it needs. Let's say, for one of these contracts, there's a special clause. It wouldn't know that in the planning step. You can't really tell what to do when it sees that, because it hasn't done all the work. Essentially, you could compare planning to working with a coworker that comes up to you. Tell us you're about the approach. You align with them and then you never ever hear from them again until they deliver the final document. It's not a super nice word to collaborate. This is a good thing we have right now, but I don't think planning is going to stay around. Then we have skills. Skills are really, really, really good. They are really good because skills allow you to encode human judgment into essentially the nodes of work that happen here. So I can say, whenever you review confidentiality, you should do it in this way. And the really good thing about this is it allows for contingencies. So here at one of the revering termination clauses, they're suspiciously you law. But I have that in a skill, so that means whatever happens when it actually does the work, it knows how to handle that special case. You can't really do this with planning. There's also progressive discovery, which, again, is really awesome. Whatever happens, it knows it will pick it up. The problem is, you don't have skills for everything. The next step is then to use the Lizitation, which means ask the user, ask the student. So you might have skills as well. But then instead of you giving all the info, it's going to come to you. It's going to say, hey, here's the thing I don't know how to handle, and what do you want me to do? This makes a lot of sense, first of all. What you don't want is you don't want the agent to be blocked. So ideally, if you implement this, what you do is you tell the agent, if you're unsure about something, make a decision unblock yourself, but write this to a decision log. So then the human should review the decision log afterwards and reverse decisions if it needs to. Now the right view expert is, if you imagine this work, this tree being 10 times bigger, 100 times bigger, you don't want this in the chat. You don't want to open up a chat, and then it's infinitely long. You have to answer 50 questions. You wouldn't know what to answer. You wouldn't really be able to do it because you don't have the right context. So not chat. Chat is one dimensional. It's a very low bandwidth interface, and it tries to collapse this work tree into a single linear thing. So what's a better interface? Well, I think humans and agents should collaborate in high bandwidth artifacts. I think they need to work in things that are maybe typically persistent. And they will look different industry to industry, vertical to vertical, depending on what task you're solving. So an example for us is a document that's like a durable interface where it makes sense to collaborate. That's how you collaborate with your coworkers. You can highlight clause three, and it will only change the clause three. You can add comments. You can tag your agents. You can tag your collaborators. You can hand off parts of the document to special agents. Another example is our type of review, which is essentially, I ask it to do the contract review that I talked about, and it's going to say, OK, let me spin up a type of review, which is like a known primitive that our users know. And it looks like this. And then it's going to say, I'm going to review all the contracts, and I'm going to just flag a few items for you. That I want you to take on. And then I can go in there, and I can see very quickly where the problems are. So it's high control. It's very effective for me to instill judgment. And I can also very quickly get an idea for what the agent has actually done. So reviewing is easy. And then once I've done that, I can just kick off the rest of the agent. Right now, what we're seeing a lot is the convergence of UI, basically this is post-talk and linear, within last two weeks, shipping this new UI. To be clear, chat boxes as input is great. I think it's extremely flexible. It allows you to do a lot of stuff. But you don't want chat to be your main mode of collaboration with a complex agent. The good thing about this is languages, essentially, the universal interface. It's what people use to communicate. You can do everything with the voice. But agents aren't humans. Just a few minutes ago, I was talking to a potentially candidate for LaGora. And I was describing our org chat. And I was limited because I can only use language. I wish that I could just draw up an org chat, and they could interact with it, and they could use it. But I can't, because I'm a human, I am limited by language. But agents are not humans. And so we should not constrain them to human language. Thank you.
TL;DR
- Complex AI agents struggle with long-running tasks and standard chat interfaces due to issues with context retention and limited control.
- Effective human-agent collaboration for complex work requires specialized, high-bandwidth interfaces beyond chat to improve trust and control.
- Agents should be designed with mechanisms like task decomposition, guardrails, and elicitation to allow humans to instill judgment and verify work at critical junctures.
Takeaways
- Planning and reviewing work are new bottlenecks: While AI makes doing the work cheap, the time spent planning requirements and reviewing outputs is becoming the most time-consuming part of complex tasks.
- Apply the Verifiers Rule: Tasks that are solvable and easy to verify are ideal for AI agents. For difficult-to-verify tasks, focus on human-agent collaboration.
- Increase trust through verifiable proxies and decomposition: If direct verification is hard (e.g., legal contracts), find proxies (e.g., similarity to "golden contracts"). Break down complex tasks into smaller, verifiable sub-tasks, leaving critical decisions to humans.
- Implement guardrails: Limit an agent's actions (e.g., "only edit these three files," "only search these websites") to increase trust and prevent unexpected behavior.
- Improve control with skills and elicitation: Encode human judgment directly into "skills" for specific sub-tasks to handle contingencies. For unknown situations, agents should "elicit" information by asking the user, ideally logging decisions for later review rather than blocking.
- Avoid chat for complex agent interaction: Chat is a low-bandwidth, one-dimensional interface that collapses a complex "work tree" into a linear sequence, making it inefficient for imposing judgment or understanding agent actions.
- Utilize high-bandwidth artifacts: Agents and humans should collaborate within persistent, industry-specific interfaces (e.g., interactive documents, specialized review tools) that allow for richer interaction, contextual feedback, and selective intervention.
Vocabulary
vertical AI — AI solutions tailored for a specific industry or domain (e.g., legal, finance).
complex agent — An AI system designed to perform multi-step, long-running tasks, often involving sub-agents, web searches, and file operations.
context-wide state — The full set of information and memory an AI agent maintains about a task, which can be lost due to context window limitations.
Verifiers rule — A principle stating that if a task is solvable and easy to verify, AI will solve it (coined by Jason Warner).
proxies for verification — Indirect methods or metrics used to evaluate the quality or correctness of an agent's output when direct verification is difficult.
decompose tasks — Breaking down a large, complex task into smaller, more manageable sub-tasks.
guardrails — Constraints or rules that limit an agent's actions or scope, ensuring it operates within defined boundaries.
elicitation — The process by which an AI agent asks a human user for clarification or guidance when it encounters uncertainty or needs human judgment.
decision log — A record of decisions made by an AI agent, especially when operating autonomously or making assumptions.
high-bandwidth artifacts — Specialized, often visual or interactive, interfaces or documents that allow for rich, persistent collaboration between humans and AI, unlike linear chat.
DAC — Directed Acyclic Graph, a common data structure used to model complex workflows or task dependencies, often used in the context of agents.
Transcript
How's everyone doing? Still good? Great. It's 5 p.m. on a Friday. There's just me and two more people behind you and Friday beer, so I'll try to be a little bit quick here. I'm here to talk to you guys today about vertical AI and complex agents and why I think they need more than just the chat. If you've ever worked with a long-running complex agent, you've probably tried something like this. Sorry, that is all white. I can see the flashbang in your guest face. You tell it's research something. You draft a contract, make no mistakes, and it starts thinking. It starts reading. Launches a bunch of sub-agents. Does web search, writes files. Launches more sub-agents. Does more reading. writes more files. Keeps going. Takes forever after 30 minutes. It gives you your contract. You take a look. Plus three doesn't look right. Did you make a mistake here? Did you look at another document? You're absolutely right. Then you see this. Compaction. That's when you know you can give up. It's going to forget everything. It's in the context-wide state. Anyway, it continues. It keeps on going. And you're going to do a contract. Does it look, was it only close three that was changed? Probably not. And so you're going to end up in this state. Not the greatest experience. My name's Jacob. I'm the CTO of LaGora. We are a collaborative AI workspace for law firms. So we're a vertical AI company. We have more than 1,000 customers, more than 50 markets. We've raised a bunch of money. We're growing extremely fast. I'm being told maybe the fastest in history. We are also hiring engineers in London. So in case anyone's interested and wants to be on this growth journey, please talk to me after my talk. Our goal and the goal of most vertical AI companies is to make agents complete more and more complex work in TwinD. That's sort of doing that has changed a lot in the past six to 12 months because there are new economics of production. So it used to be, if you wanted to complete end-to-end work, that you would be focused on doing the work. That would be sort of the main thing is actually just getting it done. But today, things look a little bit different. Because right now, planning work and reviewing work is the new bottleneck. So doing the actual work is extremely cheap. It's very easy to do. But now you have to spend time planning. You have to get the non-functional requirements. You have to get the specs. And you have to spend a lot of time reviewing the work. And if anyone's reviewed big PROS on GitHub, it really sucks. It's extremely painful. Maybe if you're a super AI-pilled, you just get your AI agents to review their own work, no humans involved. Maybe it works. Maybe it doesn't. And when we think about completing complex work, both the planning stage, the doing stage and the rearing stage, the Verifiers rule is a good way to think about work. So Verifiers rule is a term that was coined by Jason, which states that if it's a task is solvable and it's easy to verify, then it's going to get solved by AI. He was primarily talking about foundational models. So if you can make something very easy to verify, then you can do RL environments. You can post-trained. It's going to solve it. I think it also goes for agents. If you can make a task verifiable, you can just run an agent in a loop until it, hey, you did this wrong. Please fix it. And it'll eventually get there. Different industries on different places in this spectrum. It's a little bit more complex than just this, because verticals have tasks that are different places on this spectrum. So if you take legal, we can check definitions in a contract. Super easy. It's a verify. Super easy to get done. Right in contract, it's very easy to solve, but actually it's doing the difficult to verify. Because if you think about it, when you write a contract, the only time you can actually verify the language you use works if it goes to court. And a judge basically verifies it. Tell us if it's good or not. So that's actually quite complex. Litigation strategy is also basically impossible to verify. If you don't know what litigation is, it's when you sue someone or someone suits you. I know we're in Europe now, but the Americans really love doing this all the time. But essentially, if you ask five lawyers, what should be the right strategy for this litigation case? They're going to give you different answers. And so there's no objective truth, which means it's basically impossible. To verify, it's really difficult for AI to solve. Similarly on coding, some parts are really easy, building a successful consumer app. Very difficult to verify. So when we think about this, we think about how to involve humans where it really matters and let agents do the work that we can let them do. There's two things that are important to think about with agent-suman collaboration. Control is the first one. Control is how effectively can a human instill their knowledge into the work that the agent is doing. So how effectively can I steer it? Control is a matter of how much do we need to review. So if I have very low control, I'm going to look at every single agent trace and see exactly what it did. If I have a very low trust, if I have very high trust, I won't look at it at all. Depending on where the task falls in the chart, different things are important. How to increase trust? So if you want to increase trust, there's a few different things you can do. Firstly, you can bring a task down in the spectrum. So here's an example from coding. If you want to implement a feature, well, you can give it browser access. You can do a test or event development. Then suddenly, it's actually a verifiable task, and it's going to do much better. There are similar things you can do in finance and in legal. You can do some things similar as well. We don't have, let's take the contract example in legal. You can't really verify it, but you can look for a proxy for verification. So for contracts, what you can do is you can take a look at previous contracts. These are our golden contracts. We know they work well. Let's set up a test. Is it the new contract? Is it similar to the old one? That's a proxy for verification. That's going to allow your agent to do much better job. You can also decompose tasks. So here's the example with writing a contract. I can turn that from one task into a bunch of other tasks. And I can leave picking a rich profile, picking the precedent document, the negotiation stands. I can leave that to the human. But I can try to get other stuff down where it's easy to verify. So apply formatting. Make it look like all my other contracts. Apply checking definition, which is essentially the whole definition used, or all the definitions that are used to define. This kind of stuff you can build, and then the agent can basically rip much better. You can also add godrails. And godrails is essentially the way to interest by limiting what the agent can do. So instead of being able to do all of this, you're just going to say you can only do these. You can only edit these three files. You can only read these from this directory. You can only search these websites by limiting what it can do. You basically get more trust. Because you know that I won't do all these weird things. An example of this, probably all known on this one, load code. If there's very low trust, it's going to basically tell you every single time it wants to do anything, which makes it extremely useless. And on the high trust end of the spectrum, you just do all the mode it, let it rip, and hope that it doesn't delete your prod database. Then there's control. So how do we increase control? Well, if you think about complex agent work, you can kind of think about it as a tree of work, as a DAC essentially. So here's an example where I wanted to write a report on a bunch of employment contracts. So the agent's going to say, OK, let me research the organization first. Then I want to review the contracts. And I'm going to review for a few different things for each of the contracts. And then I'm going to draft a report at the end. This is extremely low control. Because essentially, I can only impose my judgment at the root level. So it's going to do all of this work, and then it's going to get back to me. And then I can try to talk to you again. And there was just basically the example I gave at the beginning. So very low control. Then there's planning. Planning essentially allows you to steer the agent up front and align one of the approach. And so with planning here, it might say, OK, you should absolutely take these steps. These are correct. These are the closest you should be looking for. This is what you want to review. So this is a good step. It gives you a bit more control. It's easier to impose what you want it to do. The problem is planning. You basically have to do all the work to just know what to do. I'm sure people have tried this in float code. You basically have to go through the entire thing. It's really inefficient. It takes a long time and asks you a bunch of questions. And in the end, it's basically impossible for it to really know if it has all the information it needs. Let's say, for one of these contracts, there's a special clause. It wouldn't know that in the planning step. You can't really tell what to do when it sees that, because it hasn't done all the work. Essentially, you could compare planning to working with a coworker that comes up to you. Tell us you're about the approach. You align with them and then you never ever hear from them again until they deliver the final document. It's not a super nice word to collaborate. This is a good thing we have right now, but I don't think planning is going to stay around. Then we have skills. Skills are really, really, really good. They are really good because skills allow you to encode human judgment into essentially the nodes of work that happen here. So I can say, whenever you review confidentiality, you should do it in this way. And the really good thing about this is it allows for contingencies. So here at one of the revering termination clauses, they're suspiciously you law. But I have that in a skill, so that means whatever happens when it actually does the work, it knows how to handle that special case. You can't really do this with planning. There's also progressive discovery, which, again, is really awesome. Whatever happens, it knows it will pick it up. The problem is, you don't have skills for everything. The next step is then to use the Lizitation, which means ask the user, ask the student. So you might have skills as well. But then instead of you giving all the info, it's going to come to you. It's going to say, hey, here's the thing I don't know how to handle, and what do you want me to do? This makes a lot of sense, first of all. What you don't want is you don't want the agent to be blocked. So ideally, if you implement this, what you do is you tell the agent, if you're unsure about something, make a decision unblock yourself, but write this to a decision log. So then the human should review the decision log afterwards and reverse decisions if it needs to. Now the right view expert is, if you imagine this work, this tree being 10 times bigger, 100 times bigger, you don't want this in the chat. You don't want to open up a chat, and then it's infinitely long. You have to answer 50 questions. You wouldn't know what to answer. You wouldn't really be able to do it because you don't have the right context. So not chat. Chat is one dimensional. It's a very low bandwidth interface, and it tries to collapse this work tree into a single linear thing. So what's a better interface? Well, I think humans and agents should collaborate in high bandwidth artifacts. I think they need to work in things that are maybe typically persistent. And they will look different industry to industry, vertical to vertical, depending on what task you're solving. So an example for us is a document that's like a durable interface where it makes sense to collaborate. That's how you collaborate with your coworkers. You can highlight clause three, and it will only change the clause three. You can add comments. You can tag your agents. You can tag your collaborators. You can hand off parts of the document to special agents. Another example is our type of review, which is essentially, I ask it to do the contract review that I talked about, and it's going to say, OK, let me spin up a type of review, which is like a known primitive that our users know. And it looks like this. And then it's going to say, I'm going to review all the contracts, and I'm going to just flag a few items for you. That I want you to take on. And then I can go in there, and I can see very quickly where the problems are. So it's high control. It's very effective for me to instill judgment. And I can also very quickly get an idea for what the agent has actually done. So reviewing is easy. And then once I've done that, I can just kick off the rest of the agent. Right now, what we're seeing a lot is the convergence of UI, basically this is post-talk and linear, within last two weeks, shipping this new UI. To be clear, chat boxes as input is great. I think it's extremely flexible. It allows you to do a lot of stuff. But you don't want chat to be your main mode of collaboration with a complex agent. The good thing about this is languages, essentially, the universal interface. It's what people use to communicate. You can do everything with the voice. But agents aren't humans. Just a few minutes ago, I was talking to a potentially candidate for LaGora. And I was describing our org chat. And I was limited because I can only use language. I wish that I could just draw up an org chat, and they could interact with it, and they could use it. But I can't, because I'm a human, I am limited by language. But agents are not humans. And so we should not constrain them to human language. Thank you.