Skip to content

Instantly share code, notes, and snippets.

@rksm
Last active July 30, 2025 20:24
Show Gist options
  • Save rksm/0ef361fb76f57accf40834f442cdaf42 to your computer and use it in GitHub Desktop.
Save rksm/0ef361fb76f57accf40834f442cdaf42 to your computer and use it in GitHub Desktop.
TWIML AI - Context Engineering for Productive AI Agents [Filip Kozera] - 741

[Filip Kozera] [00:00:00-00:00:38]

I think a lot of people think that more powerful agents mean more autonomous agents. I actually think that's false. What you end up needing to do is incorporate human feedback even inside of these reflection loops. So basically the job becomes how to make sure that the agent knows what it doesn't know. and bringing the human at the right time into these reflection loops. So when we think about how the future of work will look, it's exactly that. It's the data that the agent cannot find, the taste or creativity that it cannot come up with on its own surface to human as work.

[Sam Charrington] [00:00:52-00:01:09]

All right, everyone. Welcome to another episode of the TwiML AI podcast. I am your host, Sam Sherrington. Today, I'm joined by Philip Kizura. Philip is founder and CEO at WordWare. Before we get going, be sure to take a moment to hit that subscribe button wherever you're listening to today's show. Philip, welcome to the podcast.

[Filip Kozera] [00:01:10-00:01:11]

Hey, Sam. Pleasure to be here.

[Sam Charrington] [00:01:12-00:01:49]

I'm excited to have you on the show, and I'm looking forward to digging into a really interesting conversation, both about what you are building at WordWare and the way you have approached the problem of building AI agents for users, but also we've talked about... A bunch of interesting kind of topics around context engineering, the future of work, the fight happening at the application layer. All of these things will be interesting to dig into together. But let's get started by having you share a little bit about your background and introduce yourself to our audience.

[Filip Kozera] [00:01:50-00:03:18]

Sure. So very long story short, I actually was pretty lucky with my choice of research. I did research into essentially LSTMs back in 2016, which were the precursors to the Transformers architecture. In 2018, I started my first company trying to augment human memory with always-on listening devices based on GPT-2 and BERT. And I must say, I was a little bit before my time. It felt like banging my head against the wall sometimes with GPT-2, you know. I shouldn't promise, but not really being there. Again, long story short, ended up exiting that company, took a year off. We don't talk about these moments enough in Silicon Valley. It always seems to be grind, grind, grind. But I... Sailed the Atlantic, I climbed a couple of peaks in Nepal, and I was back at it. And this time around, we essentially approached WordWare as the new software where the words are actually the code. Hence, kind of the new take on the natural language programming. In the beginning, we were a much more developer-focused platform. We found some faults in our hypotheses. And right now, we're building WordWare is essentially a companion that helps you build other background agents. And we can get into what are background agents in a second.

[Sam Charrington] [00:03:18-00:04:20]

That's super interesting. And right now there's a big risk that this suddenly becomes a sailing podcast if we dig into that topic. But I'm going to resist that and talk a little bit more about the agentic side of things. You know, when I looked at what you guys are doing, it touched on some themes that I found super interesting. I've built a bunch of agentic workflows with tools like N8n and Zapier and Make and the like. And your proposition to users is that you allow them to build these kinds of workflows or agents with natural language as opposed to dragging boxes around and doing a lot of pointy clicky. which sounds really interesting. Talk a little bit more about the philosophy that led you down that path. It sounds like there was maybe a pivot from a developer-oriented approach to something that's more user-focused or end-user focused.

[Filip Kozera] [00:04:21-00:06:00]

Yeah, so I think the core of all of this is that The thing that matters the most right now is the natural language. It is essentially the assembly code of LLMs. And putting that abstraction front and center is very important. And At the beginning, we were much more focused on developers and then very technical users where essentially you are sending particular snippets of text to different LLMs and kind of really embracing the chain of thought technique by enabling you to also call different models. Right now, we've changed it a little bit and I can go into reasons. I think we took quite a lot of inspiration from where the software kind of vibe coding market is. I can get into like, why is that important? But we essentially want to simplify the entry point to where the engine stays the same. But we kind of want to make sure that Humans know how to express the idea and the assignment for the agent. And as long as they can write it in a document format, it can be executed. And the question there is that obviously at the beginning, the latency and the cost of it is much higher because you are essentially using a React agent. behind all of it, trying to make sense of it and not make explicit tool calls, but rather have the agent decide on what to call, what code to write, etc.

[Sam Charrington] [00:06:02-00:06:38]

Help me kind of get a mental model for the next level of detail. the user describes their problem and what they're trying to do. And is the next step like a kind of a compilation step in the sense of like, you're taking what they're trying to do. You're parsing it into, you know, what agents might need to be involved, what tools might need to be involved, or is it more of a, you know, zero shot kind of thing where you, you have created something. We just give that to a system. That's the same thing. independent of the prompt and it knows how to execute all of these things that the user might want to do.

[Filip Kozera] [00:06:39-00:08:12]

Each agent in its simplest form is just a reflection loop with ability to call tools. And when we're passing, we call it a dossier, which includes all the context needed to execute an assignment. You pass different data into it. You ideally truncate it to be manageable inside of the context window, which we know, you know, all the time we hit the limitation of the 200,000 tokens. on Opus or a million on Gemini, etc. And the assignment is the function The resources, the context, let's say, all of your data from Slack is the X in the FX, you know. And the assignment can be kind of, you know, taken as an algorithm, which, you know, uses LLMs, obviously, very, very heavily. And once it starts on the assignment, it uses a React assignment. That's a very famous paper I recommend reading and basically calls different tools in their reflection loop. And the agent itself is actually deciding on what tools to use out of its whole repository, which ideally you are kind of passing in the toss here so the execution agent doesn't get too confused. We have seen like a big, big drop in performance when presenting like even Opus 4 with more than 15 tools.

[Sam Charrington] [00:08:13-00:08:20]

Are you pre-processing that dossier to explicitly identify tools or are you allowing the agent to do that on the fly?

[Filip Kozera] [00:08:21-00:09:08]

The agent will have to choose from a set of tools, but we definitely limit the number. We have right now in our repository around like 3,000 different tools. And based on the assignments and the resources, you kind of want to limit that. There is like two different approaches. You could have a architecture where there is a continuous agent, which depending on the execution of a particular loop, iteration is actually choosing the right tools for that iteration. Or if you are very sure about how to execute this particular assignment, you can just kind of hard code it into the repository that the execution agent can call.

[Sam Charrington] [00:09:08-00:09:11]

Talk a little bit about how MCPs come into play in your architecture.

[Filip Kozera] [00:09:11-00:10:14]

First of all, MCPs are just tools. The only difference between them is that we agreed that Let's say you're running a team and each person in the team has some particular function, okay? And they know how to do one thing. And here we are kind of assuming everyone is a single task kind of persona. And all the MCPs, the innovation of MCPs is that we standardize a sticky note that you put on a forehead. of that particular tool. So when you come into the room, you don't have to know them, know them, but you kind of know if you are getting a task from your client, you as the CEO of all of these tools know to whom to give that task. And, you know, we've kind of discovered quite a lot of limitations to do with MCPs. That sticky note lacks things. So it lacks a couple of different, in the end, it's still a description. It's just, we should force people to describe it a little bit more. So things that we are adding.

[Sam Charrington] [00:10:14-00:10:20]

Sticky note is only as good as the description that people are giving to the underlying tools and what they can do. Right.

[Filip Kozera] [00:10:20-00:11:34]

So ideally, I would like to bring a world where we have an even stricter format of that sticky note. And some of the things that could be added is, you know, required context, because if you just end up calling the tool and not giving it the right context to kind of... move forward with that task that's useless. It should have a feedback in some way. So if you already called that tool and that tool returned an error, you kind of want to call it again from the main agent and give it feedback. Authority is an important one. So basically, there should be some kind of way when we are taking action in people's lives, we should know whether that authority has been given to that particular tool. And if not, then what's missing? And there's a couple more. I think those four kind of describe it well enough. But we basically always throw a JSON into that description that compiles all of these things. And most of our tools are actually agentic. So they run some kind of LLN on, you know, before they actually process and just use an API, right? In the end, it's an API wrapped for natural language.

[Sam Charrington] [00:11:35-00:11:57]

When you say you throw adjacent into the mix there, are you saying that you are adding all of those things beyond what is available via the MCP itself? In other words, you're onboarding new APIs or MCPs and you're taking on the burden of, you know, filling out that metadata where it might be deficient?

[Filip Kozera] [00:11:59-00:13:25]

Yes. So essentially, it's still, we're still using exactly, you know, the right, the same place in MCPS description. We're just populating that description with a lot more things. So, you know, the content, the task, the authority, and as long as you then do the right things with it inside of the tool, then it's all good. So that's a little bit of a problem with kind of tools that are not managed by you. And for us, you know, a good tool is essentially still has an API somewhere in there, which just learns how to parse everything into the API. But now with OR it has an actual first party MCP inside of it. So then it basically you lose a little bit of you lose out on latency, but you're a little bit more sure that what's happening inside of that tool. actually makes sense and it is what you want to do. So tools can be agentic, tools can be, hey, walk out my dog, which then, you know, calls, goes to Rover website and does browser, like browser use there and so on. That can be a tool as well. And there is like a, you know, there is a little bit of a spectrum there between what is a full powerful agent and what is a basic tool, which is deterministic.

[Sam Charrington] [00:13:25-00:13:41]

And so when you hear folks talking about these agent-agentic protocols like A2A or ACP, how do you think about that in the context of what you've learned about using tools and the more agentic tools?

[Filip Kozera] [00:13:43-00:13:52]

All of this is a schema of how to communicate between tools, or if you want them to be agentic, you can call them agents.

[Sam Charrington] [00:13:53-00:13:54]

Or software systems.

[Filip Kozera] [00:13:55-00:13:60]

Exactly. So regardless of the exact...

[Sam Charrington] [00:14:00-00:14:26]

schema i think what you'll end up doing in your own architecture is to use something that like works just for you so we don't actually utilize a to a we you know we utilize some mcps uh but providing the additional context kind of closes the gap between mcp and a to a yeah so so so that's Like, I don't know the ins and outs of A2A.

[Filip Kozera] [00:14:26-00:15:28]

I just know that, like, basically you need to find yourself on the right side of the wave. So it seems right now that an MCP is a wave, which essentially means that people are putting, you know, for the last... 20 years, we've been putting a GUI on top of databases, and that's called essentially a UX for humans. And what we are trying to do right now is we're trying to define what is the best UX for agents to interact with that particular database, which, you know, both SAS is a database with some manipulation and a graphical interface. And it's an interesting problem. I think the game is far from being over. It's just people are catching on that if you are linear, you need to actually put out a way for agents to interact with all of that data that you beautifully present to humans, but have not found a way to present to AI.

[Sam Charrington] [00:15:31-00:16:12]

So I'm really wanting to ask you a direct question, and that is, does it work? And the context for that question is, in my experience, building out agents with like, again, N8N, for example. I often will go through this experience where I'll build this fully agentic thing and leave a lot to the LLM and it kind of works, kind of doesn't work. So I'll pull more and more out of the LLM and do more pre-processing and apply my own knowledge about the problem to kind of structure it more and more for the LLM.

[Filip Kozera] [00:16:12-00:18:19]

And what you're telling me is you've got this one system, you feed it a prompt and it's going to uh just work without that kind of explicit you know business knowledge and uh i don't question that it you know will work at some point you know given a certain level of capability of lms uh but i want to you know oh that's a very valid question yeah um i think um Graceful recovery is extremely important in these systems. And in that way, I think a lot of people think that more powerful agent mean more autonomous agent. I actually think that's false. And what you end up needing to do is incorporate human feedback even inside of these reflection loops. And if the agent, so basically the job becomes how to make sure that the agent knows what it doesn't know. and bringing the human at the right time into these reflection loops. So when we think about how the future of work will look like, it's exactly that. It's the data that the agent cannot find, the taste or creativity that it cannot come up with on its own, surface to human as work. So that's on the reflection part of things. So how to figure out what tool to use and when. But there is also a part where it just lacks the right tools. It doesn't have the authentication or it doesn't have many things. So the first question for the human in the loop could be, do you have an API key for this? Can you authenticate via web? But actually what we found out is that it's good to have a graceful ability to fail in that aspect as well. And you almost need to manage a to-do list for the human. So everything where the agent cannot figure the shit out, you know, it will be like, hey, I added it to your to-do. Good luck.

[Sam Charrington] [00:18:21-00:18:33]

Got it. And is that happening, like, does WordWare, like, connect to my Slack and the agent is pinging me, you know, asking me for things? Or is it some agentic inbox on your system, like...

[Filip Kozera] [00:18:34-00:20:07]

So we're currently in a closed beta for the kind of AIOS product. And we basically have, you know, a macOS app, a web app. We're basically an agent, which is Companion, which is serving as that kind of manager and the last line of defense between you and the fucked out of agents that are trying to get some shit done. And there's an agent, there's that companion, which kind of protects you. But the rest of it is actually like there is a to-do, there is a bunch of human-in-the-loop tasks, which is slightly different. We haven't really figured out the glossaries for all of these, but a human-in-the-loop is kind of an intervention by an agent which stops for approval, rejection, modifying of the... modification of logical steps where it got itself in some kind of dead end or just kind of editing the final output. So those are the kind of four things that an agent can ask you to do. And there is also things where the agent just gives up and says, hey, I cannot do that. And then you add it to your own to do so. This is kind of reflecting on how I see humans working in like 2028. It's a lot about getting outside of this concurrency of one of chat interfaces. Maybe you have two agents doing something for you. You're closely monitoring it. You're essentially micromanaging your agents.

[Sam Charrington] [00:20:08-00:20:45]

One way to kind of look at this is look at what's happening in agentic coding tools and project that into general work. You know, we've seen the rise of, you know, these agentic swarm coding tools and like Grok Heavy is maybe an example of this as well, where you start a task and this task spins up a bunch of sub-agents that run off and, you know, do your coding task or, you know, your research task. And your job becomes, you know, the agent becomes less of an augment, a way to augment you as a developer, but a way to augment you as a developer manager.

[Filip Kozera] [00:20:46-00:23:02]

kind of thing and i've actually there yeah there's a couple of very important ideas here one it's just a companion so you still have to take responsibility of it for its work which works better than like a top to bottom push from the manager from the management of using some particular tool because then nobody ends up taking responsibility for its outputs and that's one part of our that we are better than AIs. We are a legal entity that has responsibilities, can get fired, and we give a shit. And so when I look at the current, I'm Polish originally, and when I come back to Poland, I see this human pride in implementation of very particular rules technical solutions. And these people often say, AI doesn't work. It doesn't do the thing. And when I look at the best engineers right now at my company, I think about the people who have had experience managing interns, have taste and are extremely good technically, but know which parts to delegate. And they work with tools like Codex, Devon, and like with interns, a lot of the work, you just need to throw it out. You cannot make it like get to the code base. And in the particular parts where you as an engineer understand that there is not much training data for that particular problem, then you end up solving it yourself. And this is very important to kind of understand for which problem there is a lot of training data and kind of develop that intuition to be like, hey, actually, if I would have scraped all of Stack Overflow, there was probably 400 instances of this question being asked. That's perfect. And this actually also influenced our architectural decisions. where something could be slightly suboptimal in the kind of implementation, but we know that there is a lot of training data about this particular implementation, which ends up allowing us to manage our code base with AI much better. So it is optimal.

[Sam Charrington] [00:23:02-00:23:23]

There's an interesting way of decomposing a problem in that you're explicitly thinking about what's likely to be within the training data, which I guess is another way of explicitly thinking about what the LLM is going to be good at and not, which is kind of table stakes. But thinking about it from a training data perspective maybe helps you do that.

[Filip Kozera] [00:23:23-00:23:57]

And it's crazy because we're basically choosing – like our suboptimal, you know, like architectural decisions based on the employees we have available. Right. You're not going to write your stock in Java if you only have like, you know, Python developers, you know, it's like you end up having to choose. And yeah, it's very interesting to me that we are already changing our lives to let AI help us easier.

[Sam Charrington] [00:23:57-00:24:56]

Along that specific point, I've thought a lot about how AI changes the future of developing new programming paradigms and frameworks and the like. And the example that comes to mind and illustrates this for me is agents are really good at creating React applications. That's the canonical thing that they know how to do. They're less good at Svelte or other things that I might want to do that are somewhat less represented in the training data. Or, you know, God forbid, some new thing that I want to get out there and, you know, promote for developers to adopt. Like, how do I get them to do that? Well, I've got to make it really easy for agents to kind of take all the, you know, documentation, for example, you know, becomes really key, but not necessarily for the humans, but for the AIs that will need to consume it so that they can help people write code with it.

[Filip Kozera] [00:24:56-00:26:37]

And it's very interesting of like, when are you again against the wave versus kind of being able to stay on the wave? And I think, you know, V1 of this company has been really focused on developers, which then created agents, which were somewhat deterministic and then exposed it as an API and plugged it into their code. And, you know, we got very quickly to some decent revenue. And this only speaks to how crazy the AI market is because, you know, we've raised $30 million based on that biggest round out of YC. And then soon after, we realized that we're going against live coding. A year ago, vibe coding wasn't really that big of a thing, you know? And it's just such a crazy industry. Like, I don't know if you've been following what's happening with Windsurf, but my God, it's just... Shit is... I think my main lesson there is don't get burnt out as a CEO and don't involve yourself with potential acquisitions which might fall down or don't tell your team about it because once it kind of seems like it went through, your morale in the company and your own ability to push forward. Like the Windsor has been at it for seven years and they pivoted recently and they had 10 million ARR when they pivoted. Isn't that crazy that like 2025, we are pivoting away from 10 million. Like Manos had 20 million of ARR and they pivoted away. And it's just crazy how just the bar has gotten so high.

[Sam Charrington] [00:26:37-00:27:50]

There are a lot of lessons and takeaways in the whole Windsurf thing, and that's probably a podcast on its own. But, you know, there was another thing in the news about Salesforce and Slack blocking API access for Glean, which I think has a lot of implications for a company like yours that depends on getting access to your customers' data in these silos that that data lives in. This has come up for me in discussions as well with just agents that scrape the web, and we've already seen companies starting to put up barriers to prevent agents. I think Cloudflare came out with an offering that was going to allow publishers or site owners to charge agents to come and scrape their content. You know, how do you think about that as someone whose, you know, company is about, you know, in some way kind of, you know, liberating access to this data that's in these silos or at least allowing providing another way for organizations to leverage information in silos?

[Filip Kozera] [00:27:51-00:31:42]

So it's interesting the. This is a much more difficult topic than in software engineering, because in software engineering, you own your whole code base. And, you know, we are trying to automate the menial, the knowledge worker tasks and make sure that humans spend much more time on the creative tasks. And, you know, essentially automating... all of these tasks requires the access to all of that data. If you don't have, like, access to, you know, your Google Sheets and your Notion, you cannot respond or draft a response to an email asking for a particular update about some financial metric, you know? And what I'm seeing is... three different ways that this can play out so so one is maybe two one is that like people will start closing it off and uh we can see slack basically in their new terms and conditions um basically blocks you uh from um holding a uh a a particular of flash how is it called not flashpoint that um like holding all of your Slack data. And this essentially means companies like Glean cannot really kind of answer precisely about these things. And it might be that everyone becomes really greedy and everyone who has that data will try to become their own AI agent. So you'll have an AI agent with Notion, with Slack, and they will charge you for each call. I think that would be suboptimal, and it would mean that you need kind of like a personal assistant to chat with all of these agents. And there's a completely different world where, you know, there's so much benefit from chatting with your index data on Notion via Cloud that Notion just cannot close it. And then if we would be in Europe, if ChatGPT and Cloud have access to it, the small startups would as well. I have no clue how it would pan out in America where, you know, there's not such strong, uh, anti-competition, um, Sorry, such strong, like, proactivity into kind of making sure that competition is healthy. So those are the two ways. I see different companies who are actually, in the end of the day, trying to build very powerful AI agents to try to own one particular channel. So a great example of this is Granola, who, you know, like, I can see what they're doing. Like, I can see that they want to become an, you know, universal AI agent for everything that gets said. And, you know, they basically approach it and, you know, I know the founder, but I have no data from him at all. It's just my guesses that, for example, they recently raised a round, which, you know, like it wasn't like great, but I think they might just be losing so much money on transcription and just being okay with it because they are getting like, you know, so much data and And they hold it. I ask them to give me access to transcripts to the stuff that I say. I end up processing my transcripts in a different way. And I just can't get it. And I'm like, oh, shit. So you guys are hiding this from me. And it's an interesting way in. How will this look like? How does this look like when we have the IO Johnny Ive stuff that OpenAI is paying $6.5 billion for and it just listens to everything and it's an additional hardware that you wear?

[Sam Charrington] [00:31:43-00:33:13]

I don't know. This brings up a bunch of different things for me. I think, and then it kind of goes back to a point you made earlier, which is, a lot of the apps we use are UX on a database and the value, and maybe that's an oversimplification. Maybe it's a UX on some business logic on a database. But, you know, for things like CRM and things like ERP systems and many of the tools, particularly in enterprise, like the business logic is relatively thin and the value is in, you know, the data that, you know, these users have put into this database. And if this, this front end, the front door to that is shifting from a UX to something else, to an agent, you know, Salesforce and, you know, others who have all this data are, you know, they don't want to necessarily cede that front door experience to Claude, right? By like publishing an MCP and letting users bypass, you know, that Salesforce experience. And certainly, you know, they don't want to lose the value of that data by giving it away easily. Salesforce in particular has always frustrated me in this way. I remember as a, you know, as a small Salesforce user, it's like, You know, you could be paying $50, $60 a user per month, but to get access to the API, you needed to spend another $10,000 a year. It's like, it's my data. Like, what the hell?

[Filip Kozera] [00:33:15-00:33:59]

And so it's very interesting. Yeah. Where will regulations step in? You know, based on GDPR, CCPA, you can just request all of your data and they are obliged to give it to you. But that would mean that, you know, as a startup, you might have to ask about it. Like we will ask on behalf of you every 24 hours. you know like and also like if they end up charging for it you know that's like and they might try to block it in some way unless like well GDPR is pretty like airtight like it's pretty good you own your data. I'm not so sure about CCPA.

[Sam Charrington] [00:33:59-00:34:04]

It doesn't specify that they give it to you in a way that's useful or easy, right?

[Filip Kozera] [00:34:04-00:34:59]

Yeah, but then AR steps in and hey, the user experience that needs to be beautiful for humans can be just a freaking SQL database and you'll have all the information very easily accessible and One thing that AI is great is writing SQL queries. So, you know, then, yeah, so that's the magical part, right? The whole UX ends up being a prompt with an ability to write code being, in this case, SQL and the data. Suddenly that I would call this like almost like an agent experience, right? And how quick that is, how, you know, you basically don't need any of the blocks. So, The data problem is very high up on my mind. And basically how to make sure there's like startups right now, which try to do exactly the same, but also build Slack and Notion and make sure that they own that.

[Sam Charrington] [00:34:60-00:35:03]

You commit everything to this one. Building connectors to Slack and Notion, you mean?

[Filip Kozera] [00:35:03-00:35:04]

No, no, no. Just doing...

[Sam Charrington] [00:35:05-00:37:07]

Oh, just offering everything. yeah yeah and and calls as well id so it's interesting like you know i'm thinking of like another tool that i use click up like it's essentially like a project manager like asana and over the years like they have added every feature under the sun to this thing like whiteboards and this and that and you know like a they probably do have a slack like thing and When I think about that with an old world lens, I think that like, you know, their core value proposition is like highly commoditized and they need to throw more and more stuff in to justify their license. But there's another lens that you're kind of speaking to here, which is. You know, they need to or they may end up being the beneficiary of just having all the data, like the data is what is key and important in this world that we're moving into. And the dynamics are slightly different. Yeah. Likewise, what I think about. a business like yours, like in the old world, you know, if I look at a Zapier, I think probably the most complex thing in that business is managing all these connectors and, you know, building relationships with these partners and getting them over the hurdle of like, you know, one connector at a time to build out this catalog. Whereas, you know, it's kind of, I suspect it's slightly different world for you. Like it's still like, there's still an effort that's proportional to the number of connectors, but like, You got MCPs, even where there are no MCPs, you can probably use an AI to slurp in an API and, like, make it accessible to your system. But then you still, you know, in this world, one of the parallel universes that you project, your, like, O of N thing is, like, building relationships with these companies where you're asking for their data dumps every day, which doesn't sound easy either. Right.

[Filip Kozera] [00:37:08-00:39:04]

Yeah, that would not be pleasant, especially that you wouldn't be building a relationship. You would just have a lawyer on staff, which is chasing everyone who is not like, you know, adhering to you owning your actual data. So it's the opposite of building a relationship. It's building a litigation. I completely agree. I think this will essentially which parts of your resources in that dossier that we've mentioned before ends up being something that you brought a UX for the users to add data into. um is a question mark you know you can think about like granola in the end of the day is you know it's a folder of of transcripts on which there is one prompt written and the main i think they were very very lucky that they hit the right timing after covet where yeah that like essentially crisp It used to be something that produces the noise before all the big platforms had it. And they basically created a virtual microphone and a virtual speaker that wrote, like basically sent data to both their headphones and their system. So they basically built Granola for Granola as a thing. Just because of a coincidence that they already built this way of capturing it without having to add a bot into your meeting, which I think is the main innovation of Granola. You don't have to have this awkward third thing. And I don't know if you're running Granola. I am, randomly, right now. And I don't even know about this. And other people have tried it. They just nailed timekeeping. And, you know, the product is not that complex, but it's just their way to market with it is genius. And then, you know, how are they going to progress and grow on top of that data? That's a real question mark.

[Sam Charrington] [00:39:04-00:40:15]

But if you could imagine that you have a folder somewhere on your computer with all the transcripts, you could imagine that you just find ways to add to it. doesn't matter if it's you know i'm exploring all different potential things that like end up uh end up you know combine like computing your data this is a quite a sophisticated microphone which just gets stuck into my uh into my uh iphone i just connect it like this and this is a sophisticated microphone capturing stuff for me and then later on i can just kind of you know run it for transcription which is not really which is a commodity right interesting interesting I think it speaks to this context engineering and the importance of gathering and having access to this context and you know, because that's what, you know, without that, like the LLM isn't all that useful. Like you've got your prompt, you can tell it what you want it to do, but you're telling it how you want it to operate on some set of, you know, data that you, you know, own or control or has access to, or that it can find out on the world itself.

[Filip Kozera] [00:40:15-00:41:32]

But, you know, certainly, you know, your preexisting thoughts about the thing through your calls and transcripts is going to be, you know, more interesting than, you know, you know, what it finds out, you know, the, the way for you and like, Just one last point before we wrap up this topic. It's an interesting approach to say for now all of the UXs are actually, the GUIs are actually the best way to get that data. And for example, Manas recently built in a persistent authentication. So they basically hold a little instance of a logged in version of whatever you have going on and they keep it live. So they don't have to re-log you in into everything. And, you know, for example, for me, that means like I could, you know, I actually run, have a background agent which scrapes a bunch of websites which I pay for access to about kite surfing conditions. And I get a notification through our system, actually, which tells me today's a great day. Take a 11 meter kite, not the 13. It's going to be blasting from 2 to 3 p.m. I have just put a meeting in your calendar regarding this.

[Sam Charrington] [00:41:35-00:41:41]

And that is an integration or something that you've kind of built with Manus connecting it to your system?

[Filip Kozera] [00:41:42-00:42:23]

No, we actually just built the whole thing. So essentially our companion built an assignment, the assignment, you iterate on this assignment, which is in a document format where you explain exactly what needs to happen. And then, you know, there's like little things like, I'm 90 kilograms, and I need to make sure that I take the right kite and that I choose the right tide and ebb. In San Francisco, we have flow and ebb. And ebb helps you go upwind, which is great. And I want the perfect combination of it. But ebbs and flows, they are not appearing at the same time, so they actually do not run a 24-hour schedule, which means that it's actually a complicated algorithm to know when to go to kite surfing.

[Sam Charrington] [00:42:25-00:42:33]

Interesting. I mean, that brings up a very tactical question that I had in looking at WordWare.

[Filip Kozera] [00:42:33-00:44:49]

I thought I saw something in an FAQ that suggested that you weren't enabling like always on agents that like sit in the background and like repeatedly do a task for a user, but that the user had to launch the agent or something like that but you're describing something that's completely different we have 2000 different triggers that ambient agents can act upon and uh we just like i would uh recommend uh i actually don't know when this uh is coming out but we might have to cut out this version but i would recommend every go to to everyone go to sona.ai like the finnish sona And that's our companion. It helps you reflect. It helps you be the better version of yourself and helps you be the companion that builds all of these background agents for you and sign up for a waiting list because the stuff we're cooking is pretty powerful. I probably have like I know 30, 40 different background agents doing everything from prioritizing my email, catching me up on beautifully transcribed and voiced to me a morning update. It searches for every legal document and puts it through a simple prompt of like, hey, anything weird? Or it searches through all of my transcripts applies the books that I'm actually trying to become a better leader. So 15 Rules of Conscious Leadership and the Great CEO Event and tells me about how I can do better. It collates all of my previous one-on-one transcripts and checks whether somebody is performing or not in the team. There's just so much stuff or monthly checks through all of my Slack and gives me a report on the company sentiment and where potential sources of conflict, checks through all linear tickets in order to see whether we're on track and is anyone polluting our linear board with some random bullshit. And there's a lot that's going on when I'm not working. I love it. I go somewhere and then I get a bunch of notifications and I respond to them and I get work done.

[Sam Charrington] [00:44:51-00:45:06]

That's very cool. Very cool. Awesome. Well, Philip, it was great to meet you and catch up with you and learn a little bit about what you are up to. I'll definitely be keeping an eye on WordWare and checking out the tool.

[Filip Kozera] [00:45:07-00:45:10]

Perfect. Thank you so much, Tom. I've had a little fun. Thank you.

[Sam Charrington] [00:45:10-00:45:11]

Thank you. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment