The Context Podcast: ProofKit
Featuring:
- Ernest Koe, CEO of Proof
- Todd Geist, CTO of Proof
Description:
In this episode of the Context Podcast, join Ernest Koe and Todd Geist for another installment of "This Week in AI". They begin with their experiences with Claude CoWork and their internal use cases, such as automatic time tracking. They also discuss the importance of project setup and making sure that agents have their own isolated data to keep things moving quickly and securely.
Finally, they lead into a short demo of ProofKit MCP and how you can expose AI agents to FileMaker, highlighting the differences between ProofChat and ProofKit.
You can view this podcast on Youtube, Transistor.Fm, or your favorite audio platforms.
Featured Links:
- ProofKit
- The Last Quiet Thing by Terry Godier
- Latent Space Podcast “Why Anthropic Thinks AI Should Have Its Own Computer — Felix Rieseberg of Claude Cowork & Claude Code Desktop”
Todd Geist (00:02.029)
Hey, everybody. Welcome back to another episode of the Context Podcast. We're back, Ernest and I, again to talk more about AI, which is, you know, kind of the thing that's happening everywhere. It continues to happen. Oh, yeah, this week in AI, this little segment, it's kind of a thing because like last week, a bunch of things happened again, like major things that are sort of shaping the foundations of
Ernest Koe (00:15.857)
What are we calling this? This week in AI?
Todd Geist (00:31.06)
of the economy to come and this idea of agent first thinking or a lot of ways you'll hear people talking about it. But the idea that agent is this new unit of, what would you call it? It's not a unit of work. It's a unit of intelligence maybe. And it can do things for you and for your business. And it's coming together. It's early days, but it's coming together. And every week we're seeing new announcements from the big players and the...
open source players that, that begin, can kind of begin to see the shape of what this thing is, what this new economy, this new ecosystem that is being built sort of in real time and almost feels like real time because things are happening so fast. So anything last, anything from the last week that stands out to you, Ernest? Take a pic.
Ernest Koe (01:23.777)
That's been a lot of new drops from Anthropic that are quite interesting. Every time Anthropic releases something, I go, God, I wish I just waited another two weeks, another week before I build something.
Todd Geist (01:39.95)
This I've heard this called the bitter lesson we're gonna have a we're gonna talk about this podcast in a bit but in more detail but one of the podcasts I listened to last week that I thought was really great was from the it was it was Anthropics the guy who did co-work or the team lead for co-work was on the latent space podcast which is a really good podcast
Ernest Koe (01:45.11)
That's lesson.
Todd Geist (02:09.282)
to listen to on these whole topics. And he talked about what he called the bitter lesson, which was you spend a lot of time working to sort of shim and, and, and, know, constrain the models or work, you know, get the models to do what you want. And then the next release of the models, they just do it. They didn't, don't, they don't need all that work. And he called that the bitter lesson, which, which I think is kind of what you're expressing there.
Ernest Koe (02:34.393)
Yeah, one thing that I'm noticing, and maybe you feel this too, is that the... And I think about Claude a lot in this context. I think in the early days, it wasn't really clear what Claude was, right? I mean, it was not quite... It's not a model, obviously, because he had Sonnet and all those things, Haiku and whatnot. And was it an app? What did it do, besides being a chat thing? And did it do more than basically...
was an interface to an LLM that Anthropic provided. But it's very clear now that they have been iterating on a core idea that Claude is an agent and they have an opinion of what that agent should feel like and look like. And the whole value of Claude is in its harness and in the way it expresses its agentic capabilities.
If before there was this idea that, what is the moat? The moat, if LLMs are basically free, you can get Kimi K25 or GLM, whatever that's on par with Opus or even Codex these days with the latest models from OpenAI, then what do these companies have, right? And it seems to me that
Agents are the thing, not, mean, it used to be an idea, but we're getting a real sense of what having an agent actually means in practice, right?
Todd Geist (04:08.834)
Yeah. And I think we touched on this last week. We talked about what's happening now and what's really enabling this next round of really amazing things is, the, the big providers are training post-training their models on their harness. Right. So, so, Claude basically retrained itself working on Claude. And so the, the, that agentic loop and the agentic harness gets much better for that model.
Um, and we're also seeing this with, with GPT and GPT codex and GPT, uh, 5.4, I guess it is. So, you know, this is the, models are going to be, they're probably going to work best. At least the frontier models are going to work best with their own harness. That seems to be the case. Now that doesn't mean there's not a lot of orchestration that can be done around that. But if you're just using the API, for example, to make calls to.
Ernest Koe (04:45.777)
5 and 4, yeah.
Todd Geist (05:07.734)
Sonnet or Opus 4-6 and you're doing your own agentic loop in your own code, this is the better lesson. Claude is going to be better at it than you probably in doing that. Yeah. so you have to just know that. doesn't mean you can't do loops, you can't build things around it, but you have to understand what layer you can add value and what layer you're actually maybe getting in the way.
Ernest Koe (05:35.825)
I think you're still going to be building loops. think there are a lot of agents that, I mean, think this is the other lesson that Claude is a uniquely great, that's pretty good general agent. It's a pretty amazing coding development agent. Right. So, I mean, I think, I think there are all kinds of business use cases for agents that are quite specific and quite opinionated about what they do. And we can talk about some of the things that we've working on and those have their own little mini harnesses, maybe not to the extent that Claude has and not to the extent that Claude has been.
Todd Geist (05:56.856)
Yeah, yeah.
Ernest Koe (06:03.541)
RL train on, to speak, but I think still very relevant to, maybe where a lot of the work for business systems go. Not in training or applying frontier models in the same way that they're doing at Anthropic to build Claude, but in a much smaller scale to really build smaller purposeful agents to do things in their own loops with their own harnesses and so forth.
Todd Geist (06:30.892)
Right. Yeah, I think that's, that's an important point. Like the, one of the advantages that the software industry has is it's, it's like AI is the killer use case and software development is the killer use case for AI. And so these models are getting really good at AI and in general, I'm sorry, they're getting really good at coding because of all this post-training and tool calling and things that it's able to do and the validation. That's the other key thing is code can be validated. Other things can't be, you know, like, is this a good English paper?
Like, well, you know, it's somewhat subjective. But what also seems interesting is that that doesn't seem to completely relate to general purpose things. Like, Claude is still pretty good at computer use and Excel and a bunch of other things, but there's be lots of tasks that it's not gonna be good at. Or the advantage for you in building your own agent and your own loop with your own data and your own post-training on it will be much higher. And so you will wanna do that.
But yeah, when it comes to like just having a general purpose agent right now, Claude Cowork is pretty good. So we should explain, I think we did this before, but just again to reset, Claude desktop app has three modes. You have a chat mode, which is the one that's been around forever. You have code, which is the sort of low level developer centered UI and coding experience. And then you have Cowork, which is kind of in between.
and they differ in terms of their capabilities and the security wrappers around them. Cloud Chat can really only produce a single file at a time and it's not gonna be able to build a code base for you. Co-work can build a code base for you, but it is not, it's running in its own sandbox and that might be, depending on your use case, could be problematic. Cloud Code can do anything, basically.
But so I did this last week when Cowork shipped projects, which is one of the big drops they made last week is Cowork now has projects and basically projects gives you a memory layer for your agent. So you don't have to build memory. It kind of does it on its own. then it also has, that's actually scheduled tasks were before that. But it also has like dispatch, which allows you to use your Claude mobile app to communicate with it.
Todd Geist (08:55.8)
So what I built out really quickly on top of the really cool project you built for recording screens is completely automated my time tracking at this point. In the middle of the night, a schedule kicks off of my Claude cowork that looks at all the activity from the previous day, looked at what screens I was working on, activity from Slack, from our various meetings, looks at transcripts, and generates a draft timesheet for me.
I come in in the morning, the first thing I do is open up Claude and review that and just say, submit my time sheet when it's done and it's done. Like this is huge. Completely automated time tracking is a massive win for us as a business. And I think for any business where time tracking is important, being able to do that is really great. And you know, it's done basically, which is amazing. So I I'm so still just so digging your.
your project Tesseract that lets us safely and securely and privately record our screens.
Ernest Koe (10:01.701)
Yeah, Tesseract's pretty cool. We should probably release it. I don't know. We probably do something about it.
Todd Geist (10:05.932)
Yeah, we got to do something. I don't know what I mean. We have some ideas here and we got some, I think some ideas around how to build agents for it and how to build a backend for, know, for like actually doing billing and things like that. But for our business integrated with our stack, it just totally works. And like I am already seeing a massive benefit in terms of the, the amount of time that I track now in my role, I don't have to bill.
much for clients, but I do for some things. But mostly it's just capturing all the time that I'm actually doing on research and development for the various different things that I'm doing. And guess what? It's a lot more than I thought because it's now automatic. like, didn't impact us like we're not missing billable items we can bill our customers for, but it's giving me, had, you know, when I think I'm doing seven hours and that's it, that's one thing, but I'm...
Ernest Koe (10:46.481)
Yeah, for sure.
Todd Geist (11:03.246)
kind of AI pills, I'm doing this stuff all the time and I'm spending way more time than that. I usually spend an hour before night, every night now, preparing the agents to run while I'm asleep for a little bit, right? That's actual time, that's actual cost that the company needs to know about at the very least, right? Like we need to know that that's how much time it's taking to actually do these things. And all that was just getting lost before.
Ernest Koe (11:28.325)
Yeah, think cost accounting is still extremely important. I think for me, what's interesting about Tesseract is that it's giving me an insight into where my attention goes. And it's very scattered right now because I'm basically bopping between multiple terminal UIs and multiple screens like running three or four sub-agents doing stuff. But Tesseract sees it, right? So you can see not just the quantity of work, but where the...
Todd Geist (11:39.854)
That's right.
Ernest Koe (11:56.934)
where your attention is getting split and how things are getting put together. it's quite interesting. But not to focus too much on Tesseract. I do want to pick up this thread where I think we're starting to learn about building engineering software differently for an AI world. I think we've got some, Tesseract I think it's a good example of this where
Initially I thought I needed to do something like pieces, like we used to build a whole screen voice audio capturing pipeline plus storage plus this plus the AI part where you does a summaries plus the UI. It turns out small, lightweight, very purposeful and just very reliable. And you can count on it's still better than way better than the other modality.
Todd Geist (12:37.774)
plus the UI for everything, yeah.
Todd Geist (12:50.87)
way better.
Ernest Koe (12:54.583)
And I find that part of being agentic is to be able to rely on dependable tools, but to put a whole bunch of things together in either pipes or in a collection of capabilities and skills that you have access to.
Todd Geist (13:09.942)
Yeah, skills. Yeah.
Yeah, think, I mean, I think Tesseract is a good example though of a trend which I keep bumping into. You don't need a lot of UI for Tesseract, right? The agent is gonna do what it needs to do to find the data and find the things that it needs to be able to answer the questions. So you get a tremendous amount of value out of just having the underlying capture and storage of all the memories of the day.
And then the agent can just explore those memories and make a UI for you. I started experimenting a bit with that over the weekend. was really interesting.
Ernest Koe (13:48.882)
think that's key. Agents are aware your interactions are happening, for me anyway, significantly more than anything else today. spend most of my time either talking to Claude or Mira, which is my own agent, which I always regret writing because Claude keeps like, know, shipping features that make it obsolete.
Todd Geist (14:17.014)
At some point you just can point Claude at the code base and say, make me a co-work version of this and it'll do it.
Ernest Koe (14:21.361)
think I co-work on first things actually. But you know, it's the thing, we wait, I mean it's already there, but in the few, and not, I'm sure not so far in the future, we're gonna get MCP UI and UI things that can be injected directly into an agent UI, which basically makes the application UI that we were so reliant on before mostly obsolete.
I only need Tesseract to show me that it's running. And basically it, right? Everything else is happening elsewhere.
Todd Geist (14:53.71)
That's it. Yeah. Yeah. No, it's true. I think there is like, one of the things I noticed about my review process is it would be nice to have a really nice visualization of the time, right? And I don't have that, it could be added with MCPUI. And if we get to it, we can show what that looks like in an example a little bit later. But I think the, you know, just to, so when I,
finished building out this cowork agent to do my time tracking. So then the thing is how do we share that with the team? And so I could just take like that folder that had some of skills and, and a little bits of code that it needed to do whatever it needs to do. And, you know, and I could say here, put this in your cloud and, and, you know, maybe it'll work, but there's actually another way. think this is another really important trend is you can actually just have documentation.
for Claude to build its own version of it. And it works quite well. So instead of giving a bunch of documentation for a human, just, this is what I did after I was done with my agent was working great. I said, okay, here's the problem. I want to share this functionality with my team, write a prompt for Claude, for you that a person can put into their Claude and have it into their cowork and have it build out the same thing.
And I said, ask the user some questions about what their sources are and, and you know, when do they want the automated things to run and then write it yourself. Right. And, and it does it great. Like it has no problems doing it. Right. So instead of delivering a functioning code base, I delivered a prompt that allows the user to go through a process of customizing it for themselves by picking.
Do I have Slack connected? Do I have GitHub connected? Whatever the sources are I'm pulling this data from. And it will do that. And then it will write it over for them, customized for them, which is really interesting.
Ernest Koe (16:58.449)
I'm always surprised by how little agent context you really need to give something like Claude for it to actually get it pretty good on the first shot. I I think there used to be a way of thinking where you have to write very, very good prompts and that was your job. Like, the prompts have to be perfect and outline all the details of every single thing that had to happen and all the steps that you need to take and...
Todd Geist (17:10.456)
Yep. Yep.
Ernest Koe (17:26.649)
mostly bootstraps itself into something pretty viable without a lot of intervention these days.
Todd Geist (17:32.844)
Yeah. In fact, one of the other trends is people are saying, delete your Claude MD or your agents MD.
Ernest Koe (17:39.333)
Well, I second that. find that Lina, Claude, and MDs are actually better. For sure.
Todd Geist (17:43.928)
Yeah, they are. Yeah. So there people are doing things with skills, which is one way to lean them out. then what's going skills can be a little hit or miss depending on the, on the model that you're using. Anthropic models are really good at it. The open AM models are pretty good at it. The rest of them are, I think not as good, but what, so the shim that people are using right now is they basically just, they just reference their skills in the agent MD or the cloud MD. And that's it. That's the only thing that's in there is just some like,
Ernest Koe (18:10.159)
In the cloud MDH and MDM. Right.
Todd Geist (18:12.812)
links to if you need to know about this, go here, use that skill and it does it. So that's interesting. you're actually, I think it's important to say that this works best when you're using the really intelligent models, right? so, yeah. And so like another thing that's very clear is like when you're setting up a project, the setup is really important because if you'd get it set up in a...
Ernest Koe (18:28.027)
the thinking reasoning models.
Todd Geist (18:38.934)
in a way that's inconsistent or weird or that can later confuse the model. Or yeah, right. Exactly.
Ernest Koe (18:42.799)
Or conflicting, Where your cloud MD does one thing or your agent's MD does one thing and your skills does something else and then you're chasing yourself. Right.
Todd Geist (18:51.414)
Yeah. And your code base does something else. You have a problem. So code is the source of truth, right? And agents are getting better and better and better at understanding, just being able to ingest the code as needed and understand, understand what to do, which means that in a weird way, architecture, project setup, like understanding how to get a project set up correctly early on is going to lead to
much better outcomes down the road. So it turns out we still have jobs for at least a while.
Ernest Koe (19:27.589)
think I'm getting more free time. I don't know about you, but I feel like, okay, it's the opposite that's happening. I'm busier than ever and I can't find enough time to do, you know, like I've got way more work than I know what to do with it seems like. I think there's a bug in this thing, right? And it goes to something I think we, I think, I don't know, you may have read, I think you read actually. Mike shared an article with us.
Todd Geist (19:31.362)
No, that's right. Yeah.
Todd Geist (19:54.712)
Yes, the last quiet thing.
Ernest Koe (19:56.366)
last quiet thing out. You want to talk about that a little bit because I think it's relevant the whole story.
Todd Geist (19:58.786)
Yeah, yeah, really, really important article. We'll have a link in the show notes, but it's great. The Last Quiet Thing by Terry Godier, who I have not encountered before, but it was really impressive piece of writing and really nailed, I think, some of the issues we have. Actually, even in the pre, it's not really directly about AI, but it sort of is, you know?
Ernest Koe (20:25.029)
Yeah.
Todd Geist (20:26.568)
I think he starts out by talking about how like your watch and your phone and everything is constantly notifying you about things that you need to do, right? And he has a lot of interesting ways to describe this sort of weird like stress that this creates. I think we all feel it, right? You know the notification problem is real and there's this need to like dive in and take care of some notification.
And so we have all these things, which I really love. Like I actually love having all of my Apple health stuff available to me. But that all, and all the other things that I have that are, feel very powerful, but they do come at a cost. And that is they're constantly pinging you with updates. And I thought the thing that he said, one of the, the phrase that stuck out is, is that he realized that these weren't that what he got was just a bunch of jobs. Is that every one of these things is now a job.
that he had to monitor and deal with and own in some way. And those jobs used to belong to people, right? And now they, know, like your ring goes off because somebody, your Amazon ring goes off because somebody's at your door, or maybe it's at your building downstairs. And we used to have doorman who did that. And frankly, having a doorman would be way better than having something that just buzzes you all the time, right?
Ernest Koe (21:48.346)
I think there's something really important in that article. I spent this weekend mostly doing analog things, things that I have been languishing in the background because I've been in AI land for so long, know, months now. I had to re-crimp and rewire some ethernet in my house because I needed to get Wi-Fi to the right corners of the house and all that. I helped my in-laws with some plumbing and...
It was really funny because I was thinking about this and I was thinking, why does my father-in-law ask me to deal with the TV and the internet and the wifi and the plumbing things? It's not like he's a very well respected doctor, know, like really brilliant guy. And I didn't realize that.
Todd Geist (22:37.102)
you
I know where you're going with this and it's so right. Yeah.
Ernest Koe (22:45.755)
partly because he didn't want it to be his job. It's not like he couldn't. It's just like he just didn't want to take on one thing that would create all these impositions on his own time and mental space. And I thought, God, that was brilliant. So he gave me the job. gave me the job. And now I'm happy to help.
Todd Geist (22:51.15)
That's right.
Todd Geist (23:06.126)
Yeah, he gave you the job. Yeah.
Ernest Koe (23:11.675)
But you know, was recrumping my ethernet thing and I just realized that this whole thing just like hit me like a lanyard. Like, I've been doing it all wrong. used to be that because I knew how to do networking and I understood how to like deal with twisted pair and ethernet and wifi and I'm buying my own access points and mounting them around the house. And guess what? I became tech support. So.
Todd Geist (23:38.382)
That's right.
Ernest Koe (23:38.691)
Anytime anything happens, it's my job and it's never ending. Like I'm checking for coverage, I'm checking notifications to make sure things are working. You if somebody complains like, like, okay, well, I have to go fix it. You know, anyway, I think, yeah.
Todd Geist (23:43.182)
That's right.
Todd Geist (23:54.754)
I had the same problem with our sprinkler system. I had to do a whole bunch of stuff to get it back online this weekend. And it's like not stuff I really wanted to sign up for. It was not on my plan. You know, it was not on my job description, but it's my job because it's, I'm the one who can do it. I'm so I'm the only, the only person who is, who, knows enough in the house to, to make sure the, the, all the automated sprinklers are working properly. And
Ernest Koe (24:01.787)
Right.
Ernest Koe (24:08.689)
Perfect.
Todd Geist (24:21.714)
I think this is, mean, the article is great and I recommend everybody read it for a lot of reasons, but the thing that's hitting me is, and what I recognized was initial right away in two ways that impacts our business and our industry. One is like, is everybody going to do their own software? And the answer is no, like I just, because what every single piece of software that you're building is a job. And I don't want the job.
Right? Like I can do it. I can write, we could write all the software that runs our entire business, but I actually don't want that to be my job. I want that to be somebody else's job. And I think businesses are going to make that decision. Now they may choose to build more than they did in the past and they'll be able to do more than they on their own than they do in the past. But do you really want somebody at your company's job to be the accounting software? No, you just don't.
Ernest Koe (25:19.995)
I think this is critically important. I think I'm somewhat reversing my initial anxiousness, I think maybe is the right word, about whether or not this business that we call software development, custom software industry, is still relevant, given that everybody and anybody can write software. And I'm realizing that, because I'm writing a lot of software, that
It's not clear that writing more software that's actually good or healthy in that you are basically owning the whole category of responsibilities that you are not, A, maybe not resourced for and not gonna be paid for and C, you have no way of actually supporting in a healthy long-term way. I think that's a calculus we haven't figured out how to deal with yet. But I think you're right. I don't think that.
I think that businesses and companies and people are going to want more software and more capability, but it's not clear as I mean that that means that they're going to do it themselves.
Todd Geist (26:25.614)
That's right. I mean, I think some will and some won't and they'll be able to choose differently than they were in the past, right? I think they may choose to build some things, but they're certainly gonna choose to have somebody else build other things because it's just, again, I want somebody else to be responsible for this. I don't think that goes away. Like, why would it? Like, just had somebody just came to fix...
my hot tub, it had a broken sensor. It took the guy who knew how to do it 15 minutes. I probably could have gone on YouTube and probably could have found some enough videos and figured out how to do it, but it would have taken me an entire day. And I don't, again, I don't want that to be my job. Somebody else can do it way better than me.
Ernest Koe (27:17.393)
Do you still think SAS is quote unquote dead?
Todd Geist (27:22.934)
I think it's going to change. I suspect, I do think it's gonna be a lot more software built. My best guess is that it's going to be, we're gonna see the rise of more vertical type things where domain specific knowledge outweighs general stuff. Like Salesforce was successful because sales was...
you know, it was a relatively well understood domain. Everybody did it approximately the same way and they did it well and they amortized the cost over, you know, whatever it is. I don't know, 20 % of all businesses in the country or whatever it is, I have no idea. But that came at a cost, a huge operational cost for them and people have these bloated software that does way more than they need. So I suspect that there will be more Salesforce
And there already are, like Pipe Drivers, there's a million of these. I expect there will be more sales tools and there'll be more accounting tools. There'll be more whatever tools available. I think the prices will come down. I think you may make choices differently. you know, had this, I've been reading the Mars trilogy, which we talked about before, and they have a lot of ideas around like sort of co-ops and partnerships. And like, what if one model is that, you know, you have a software development firm, maybe,
is partners with a dozen or two dozen companies, and they're the ones who build the software for those two dozen companies. And you join a quote unquote co-op where everybody pitches in to have one company specialize in the software that all the companies share in. I think a lot of these different kinds of models will be tried. I don't know which ones will succeed, but it is true that software is cheaper to build. So the implementation costs are lower.
but taste and expertise and responsibility are still critically important. They're not going away. So somehow companies will choose to offshore some part of that by just by not being their responsibility.
Ernest Koe (29:35.6)
Yeah, I think.
It's hard to say. I think I share a lot of the same notions. think that using constrained-based thinking for a minute, the cost of software, I think we talked about it as the upfront cost of actually building the thing. Lots of engineers, design time, whatever, market research and testing to get it really good. And actual programming time, the actual code development.
There's also the cost of support and the cost of maintenance and the responsibility of it working reliably. I think those things are still unknown. I'm guessing AI will be a big factor in reducing some of those costs, where small teams can do a lot more support for a lot more people and so forth. But it's still a thing. And I don't know if.
businesses have to wear with all to actually have their own support team for their own business systems entirely. So I think those are still a little bit challenging. But I will say that I think for sure the cost of experimentation, the cost of getting to some kind of differentiation that you couldn't have before have dropped dramatically. And that's good. I think that gives
Todd Geist (30:41.398)
own stuff.
Todd Geist (31:02.648)
Yeah, that's good. More competition, more opportunity. That's really good. One of the other things that was really interesting in this late in space podcast about Claude Cowork is they were able to Claude Cowork in like 10 days, but that's really not accurate. They got the idea to ship something and 10 days later it was shipped. But the reason they were able to do it so fast is because
Ernest Koe (31:03.747)
I think that's good. I think that gives businesses exactly.
Ernest Koe (31:24.1)
Yes, not accurate.
Todd Geist (31:31.746)
they have dozens of experiments going on in house all the time. So Anthropic is running all kinds of things. And they have labs, which they're basically, their mandate is do something that's unlikely to ship essentially. Like that's so crazy, it's unlikely to ship. So they had like a dozen experiments of different features that ended up just getting pulled into cowork very quickly. So they were already doing all these experiments. And so that's...
Ernest Koe (31:40.443)
Right.
Todd Geist (32:01.004)
I think another thing is that, you know, even if you spend, even if you spend as much as you did before on building software, the software you're going to get is going to be so much better because you don't, you can try 10 things and pick the best one. used to be like, you had to decide before you went to implementation, okay, we're going to do this path. And you had to do all kinds of like user, user surveys and questioning and
Try to take your best guess at what would be the best solution to solve this problem. And then you gave it to the coding teams and they would spend a bunch of money building that. And now you don't. You can just say, well, let's try these five things because you can try them all. And so that's what they're doing. They're like trying every idea. not having to pick before it actually gets built and they can test it in front of people, which is a really new way.
Ernest Koe (32:51.247)
Yeah, I'm very hyped up about this idea because I think along the way we forgot what the purpose of design or guess design processes or design thinking was and it became about more the process than the goal. And really the whole point is to fail early and fail often so that you can test the best ideas and get the right...
What you don't want to do is to spend a lot of time wasting time and money and resources and treasure on things that are hard to change afterwards. But if you can ship early and get a whole bunch of ideas out on the table and validate them, and this is also important, you're not validating what people say they want. You're validating their experience with...
the prototype of the effort, the actual thing. That's actual testing. That's not market research validation where you go ask somebody, hey, what do you think about this feature? Everyone's going to say, yes, I love it. They don't actually tell you what you want to know. But when they're actually using something and you can see the usage stats come back, that's a different story. Now we can do that. Now we can do that at scale before.
Todd Geist (33:35.182)
actual thing.
Todd Geist (33:46.978)
Yeah. Yeah. Yeah.
Todd Geist (33:58.478)
Totally different. Yeah.
Yeah, like design was kind of forced to optimize, to reduce the risk of going into implementation, like to try to have the best possible plan for implementation. And we've all known that was always risky because once you start writing, the rubber meets the road and everything changes, right? It's like they say about battle plans, it only survives after the first engagement. It's the same thing. Your great designs don't survive past the first user engagement.
Ernest Koe (34:10.277)
Right.
Todd Geist (34:31.838)
Right? Like everything changes the minute it gets there. So now we can actually use design thinking without having to stop at that bottleneck. And we can just go right through to here's 10 different ideas. Try them. Like let's write them all and see what they see what they do. Yeah. Prototyping.
Ernest Koe (34:43.621)
Yeah, test them, prototype it. Yeah, no, think that's solid. So I want to come back to this notion that we touched on. I think we've been talking about it in, I think we almost take it for granted now, but we should spell it out. I think we've been talking about a way of thinking about AI that is different than the way we've been thinking about software development in the past. And I've been calling this like the two systems of thinking. One is where,
You think about using AI to just accelerate the way you work as a programmer. Call it one way of thinking, one system, one mindset. And I think what you and I have been talking about and really exploring, which is the other, which is we're not writing code anymore, practically speaking. Agents are writing code. And what we're all doing now is working with agents and building harnesses, building the tools, building the...
the scaffolding to allow our agents to actually be doing the work. And that's sort of like the second system's way of thinking about the whole system. Call it agentic system development, agentic system thing. I don't know, come up with a better term. But first system, you're a faster developer. Second system, the agents are doing the work. And I think this has really
deep implications because it changes the way you think about your tools and the software that you want to work with in general. In my mind, if the tools are not compatible with the second way of working, agentic development, then they're not really relevant anymore.
Todd Geist (36:19.32)
That's right.
Todd Geist (36:33.806)
That's right. It really changes. It really changes. And it's subtle in the different layers of effects it can have. It's certainly like there are tools, are Sass products that we have that I do not go to anymore because they do not fit this model well. They're not designed for agents to work with. They're designed for humans to work with them.
And so there's that, like you just start choosing tools that your agents are good at, right? Because, you don't do that because of some, know, hype, like at least I didn't, it's not the hype or it's not the story, it's just reality. Once you're using agents to do your work, you very quickly self-select out, you just select out the tools that don't work in that mode. So, you you tend to, just write, I prefer Markdown over any other.
note taking app that there is because agents are so great at it. They don't need any tools to do markdown. So we just use markdown, right? Simple. And I think that's gonna play out across the whole ecosystem. But then there's these other subtle effects like who are you writing documentation for? To use your tools that you're building. Do you write it for the humans or do you write it for the agents? Really probably write it for both, but if you're not writing it for the agents, you're missing an opportunity.
So I'm starting to see this in documentation for products that we use or especially the developer tools, which tend to lead in this area. Developer tools will now have whole sections of the documentation that say, basically give your agent a link to this page and tell it to go. And the agent reads it and implements the stuff into your code base. So it's that kind of thing. And it's like I mentioned before about my time tracking thing. I didn't deliver people working code, I delivered them a prompt.
that the agent's gonna use to actually write the code, right? It's that kind of thing.
Ernest Koe (38:31.589)
Yeah, I think this is quite interesting and important. I I want to kind of tie this into a couple of things we've been working on. And just quickly, maybe to share out a little bit. So I shipped a repository Sentinel, like a security leaks checker system this week. Yeah, it was actually really interesting.
Todd Geist (38:54.478)
Yeah, that's another good example of that, right.
Ernest Koe (38:58.821)
how that evolved because I was definitely in system A thinking, which is like, I'm gonna make this thing, I'm gonna use AI to make it better, and I'm gonna see what bugs happen, and then I'm gonna use that to then feed it to, I thought I was in systems B thinking, I thought I was actually programming agentically, turns out I hadn't gone all the way there, right? And that had dawned upon me that, well, what if it could just fix itself? What if you wrote it so that it was actually taking
the results of any bugs that came out in the workflow and the process, and fed it back into itself as a GitHub issue. And then it could monitor that and then fix itself by just making those agent calls. This is not a new idea. I mean, this sort self-referential thing has been the thing that we've been sort of thinking about and seeing out in the world. But I didn't think this was going to work. And I especially didn't think this was going to work, given that I was using a very primitive workflow solution. I was using GitHub Actions.
It was like there was no special cron job, and there was no special demon running. It was just like this stateless serverless thing that just kicks off every few hours and just runs a workflow. But it turns out it totally works. I came back. I was like, oh my god. It just found a bug. I tied it to KimiK2.5, and then I switched it to, what did switch it to? It doesn't matter.
But it was really surprising how cool to watch it fix itself, to do its own PR, to merge the code. And it's like, OK, my job's done. But I think this is what we're talking about. So when you're building for agents, it's not just about instructing and prompting the agent then do the work. It's actually creating conditions for the agent to.
Todd Geist (40:45.646)
It is,
Ernest Koe (40:58.956)
be able to bootstrap itself in a way. I kind of joked that maybe it will bootstrap itself into consciousness. I don't think we're there yet, but it's not clear to me that it won't do that for me sometimes.
Todd Geist (41:05.57)
Yeah.
Todd Geist (41:11.864)
Yeah, like the, so a couple of little other examples of that is like, when you're writing an API or like an MCP server that needs to work with something and there's an error state, if you're writing for the agent, you make a nice error for the agent and you suggest additional things that it could do and test. And this is, this is the magic sauce because the agents now they get back an error, they read it and they go,
Ernest Koe (41:32.75)
Right.
Todd Geist (41:42.094)
I, this giving me some suggestions here. It's giving me some prompts I can use and it'll just do it. Right. So instead of just giving some error that doesn't, it's not helpful. And, know, letting the human just say, well, it didn't work. If you give a good error to the agent, like, um, you know, I was doing this thing where, uh, which, well, which we're to look at in a little bit, um, asking a file maker file, if it, um, uh, to get the relationship info for a particular, um, table and.
If the table name's wrong, I could just, you know, give an error. But if I give a nice detailed error, that's good for the agents. Then the agent knows how to try again. So like, for example, in this case, if there's no table name that gets passed in, in the error, I say, here's a list of all the table names that are in this file. And so now the agent goes, I thought it was, you know, contacts with a C, but it's actually these guys use contacts with a K because they're German or something. I don't know, whatever.
Ernest Koe (42:30.086)
Right?
Todd Geist (42:40.64)
It sees it and goes, here's the table name. So now I know which one to do. So if you give hints back to the agent, then the agent will just fix itself. It'll just, it'll just keep doing it. And so that's another way in which it's like this, this second way of doing things where you always want to make sure you're giving the agent what it needs to make its next best guess because the agent loop is going to do it. It's going to pick it up and run with it. So yeah, that's another one.
Yeah, so like everything I build now is my goal with building any application that I'm building is what I want it to be set up for that I can simply talk about features and it can simply implement them and test it every way that it needs to test it to make sure that it didn't break anything that everything works. And now that we have like agent browser skills where they can actually, they can actually, if you're building a website,
or FileMaker WebViewer widget, you can actually have the agent just inspect the webpage itself and determine whether or not the button is green or blue or whether or not there's an error in the console. And then it just closes that loop. So it's all about setting up the project for the agent to just be able to take whatever you tell it and make a feature, test the feature, ship the feature, write the PR.
have it run through CICD, validate that everything worked and then ship it. So that I don't have to do any of that. That's always my goal now. Self running repos basically.
Ernest Koe (44:13.521)
Yeah, yeah, I think that's right. think we've been pushing in this direction, I would say. I don't want to frame it as a super intentional, well planned idea from the get go, but it certainly has been what's emerging. But I want to highlight a couple of things that you
Todd Geist (44:31.01)
I mean, it's just what's emerging in the space, right? Like it's what's happening. Yeah.
Ernest Koe (44:41.371)
that you mentioned, which feels, that resonates with me. Like one, the level of concern for me now has shifted to design in a weird way, to taste, to the goals of the software and to the experiences and feelings I want to create and significantly away from the details of how it actually gets done, right?
think that's the right separation of concern. I think in a way, you want to think about what agent-first development means, it's something like humans define what this should do, why it should do it, and how it should feel when that thing does its thing. And then the agents do everything else in achieving that vision. And it's actually quite good at that today. I think I'm even underselling it. It's better than I am at doing that today, for sure.
Todd Geist (45:29.016)
That's right. Yeah.
Todd Geist (45:36.79)
It is, just with the one caveat that still seems very clear. I don't know how long this, how many model versions this will survive, but in some ways it's interesting. Like if you know nothing about software and you don't care what it writes, you're in sort of this free place where you can just build things and you don't care about the implementation details. And that'll get you way farther than you ever could before. There's no question. But I think if you're going to ship things that are maintainable and will run and not crash and
you know, are available, high availability and can be maintained over time. At least for the time being, getting that project set up properly is, software engineering. That is the software engineering that we have today. It's basically about setting it up so that the agents can run and it's not insignificant. And there are challenges and some platforms are better suited for it than others. And in fact, some of the goals that we've had for our file maker stuff is how can we make file maker as,
Ernest Koe (46:14.491)
It still matters. Yeah. Yeah.
Todd Geist (46:37.098)
as friendly to this kind of development as possible. And there are some real challenges there. And we've broken through some of them, but some remain. But that's actually, I mean, it's serious engineering. have to know what you're doing to set all this stuff up. It's things like, if you can have many, many agents running on your code base at once, you can't have them all hitting the same database for their testing. So you have to have completely isolated environments that
these agents can spin up to work inside so they don't bump into each other or crash into the same databases or whatever. And this is a challenge. For some platforms, it's a bigger challenge than others, but you have to do that. Otherwise you can't do multiple agents, right? And that I think, we didn't say that, but that's actually a very important goal for me is that I want to be able to have the code bases that I set up have many agents running on them to fix things and add features.
as I can manage, which means they each have to have their own isolated environment, which including databases, which is always where it gets tricky if you have to deal with state. What other services, email, whatever, you have to have something that can, that will allow this to run in a completely isolated way so that each agent gets a clean slate. And when it submits back as a pull request can be merged into the master branch. So it's not just agent first, it's actually many agents is what I want, right?
Ernest Koe (48:02.641)
It's interesting.
It's many agents first. Yeah, think having strong opinions about architecture and how things should be designed and how they should function from a systems perspective still feels really important, I think, like you said. I wonder how soon before we get Claude and these other agents to kind of bootstrap themselves to saying, all right.
Todd Geist (48:06.67)
Yeah
Ernest Koe (48:34.393)
You clearly don't know what you're doing. Let me give you three patterns. Pick one and I'll test it for you. Don't worry. We're going to do decoupling this way.
Todd Geist (48:44.706)
I think it's likely to be a solved problem by either, if you pick the right infrastructure that can be isolated and the models get good enough, then I think that part of it will be a solved problem at some time in the future. And then it's just about taste and domain expertise that you bring into the table, which is still a tremendous amount, right? Still a tremendous amount of stuff that...
Ernest Koe (48:51.451)
Right.
Ernest Koe (49:08.337)
Still a lot.
Todd Geist (49:12.058)
that you need to bring to the table to be able to create something that has value beyond your own niche needs.
Ernest Koe (49:20.529)
So speaking of taste and stuff we're working on in agent-first workflow, so we've been doing some pretty cool things at Proof to really shift at least a lot of a pharma development space work into this modality, And let me set it up real quick. I think what we want to do is maybe talk about ProofKit MCP. We should build some ProofKit. ProofKit is something that we've had for a while now. It's a...
a framework for spinning up web-based projects that use FileMaker as a potential backend, but not just FileMaker, could be SuperBase or other things like that, that basically gets you all the tooling and framework and things that you need set up before you get going.
And so we're now extending this to the AI space with ProofKit MCP. Maybe Todd, you want to take over and talk about what we're doing here?
Todd Geist (50:26.22)
Yeah, so again, it's this idea that I just mentioned about wanting to make FileMaker expose as much of FileMaker as we can to these agentic types of coding experiences, because that's where the work is going to get done. I can't stress this term strongly enough. People will not be using IDEs if we...
Things like Scriptmaker will not make it through this bottleneck unless it can be reached and edited by an agent. I feel very strongly about this. just don't think there's any future in which you need a custom code editor for a particular project like we have with FileMaker because of, you know, it's...
The value that it brought to the table for many, years was the no code or low code or like, you know, even, even the, but maybe just call it the fourth GL where you didn't have to know the tech space programming. That value is by is completely eroded by AI. mean, I just don't know how else to soften the blow that that is just the state of, of the world. coding and script maker used to be faster than coding and TypeScript. That is just not true anymore. And so in order to, for FileMaker to continue to
to thrive in this new world, we want to be able to expose as much of it as we can to the AI agents. And so the first place that, the first most obvious place that we can build something is built on top of ProofKit. So ProofKit has always had this concept of building web viewer apps, which are these apps that live inside of FileMaker and...
but they're basically based on web code and they connect to FileMaker. And this became possible really in FileMaker 19.6 when we could call scripts and send data in and out of the web viewer, right? So that we've been building on that for a number of years. So the next step is how do we then continue to expose that underlying stuff that we built on ProofKit to the agents? And so a good way to do that is through an MCP server.
Todd Geist (52:48.46)
So let me spin this up and talk a little bit about it. Ernest, feel free to interrupt or say more as I get going here.
Ernest Koe (52:58.917)
Yeah, as you spin that up, I just want to stress one thing. I get that we can probably write lot of scripts in something like Claw to Codex and copy it into Scriptmaker and paste it. I think what Todd and I are sort of doubling down on is that that is not an agentic first development environment. That is still a human first development environment that is deaf assisted by a augmented by an
Todd Geist (53:22.36)
Yeah. Yeah.
Ernest Koe (53:28.451)
and agent. We want to that entire loop end-to-end agentic, meaning that there is no, while humans can be part of the process, that they shouldn't have to be part of the process of making software come to life. So that is the idea here with ProofKit MCP, which is to bring agentic development to the FileMaker platform, essentially.
Todd Geist (53:57.016)
Yeah, and like we actually, we talk a lot to Clarice about how can we like make scripts editable by agents. Cause I think that's actually really important. But that's a, you know, a couple of years ago or a year ago, maybe even the loop with agent decoding was you told it how to make the code or, you could chat with it or write code. You'd run it, there'd be an error. You'd copy the error, you'd paste it back into the agent.
And then you'd say, fix the error. And that was amazing. That was like so great. But now I don't want that copy paste thing to happen. The agent should be able to get the own its own errors. Right. That's the key. So,
So what we have is we built an MCP server that can connect to FileMaker locally. So I can run a script here in my FileMaker file. This is a simple FileMaker file, kind of the same demo file that we used for ProofChat. But we've just kind stripped out a bunch of stuff and left just the basics we needed for demoing this.
And so we have instead is a connect to MCP. And so when I run that connect to MCP, get another window. Let me actually open up another.
Todd Geist (55:24.878)
And so this little window pops up and it just shows this little screen here, which says we're to the as ProofKit MCP server connector, connected to the CRM demo. And so Claude now knows about this. And so if I go in and look at my connectors and I go to ProofKit MCP, you can see I've got all these tools here that
are connected directly to this FileMaker file. So it's open on my desktop. Whatever I have authenticated access to the FileMaker file, Claude has access to now. We're still relying, we're relying nicely on the FileMaker security privilege sets. We're not getting around those in any way. We're not having to authenticate to the FileMaker file in some special way. I am the user, I log in, I have whatever access I do and that's it, right? So once we have that, then we can...
we can start to do things. So I'm gonna start here in chat just to make a couple of examples and then we'll keep going. I'm gonna use voice to prompt, I usually talk to my agents.
Todd Geist (56:34.264)
There is a FileMaker file connected here. Take a look at the file and I don't know, let me know what is it good for? Like what does it do? Tell me about its structure and what problem it might be solving.
Todd Geist (56:53.176)
So I'm just gonna let it go to town here and it's gonna go into this agentic loop and it's gonna start exploring the connected files and it's gonna be able to get a bunch of metadata out of the files and, whoop.
Todd Geist (57:15.502)
Let me make sure I've got this connected to the right file here.
Todd Geist (57:25.048)
Hmm.
Todd Geist (57:57.518)
Let me just try this here. We may have to start this demo.
Ernest Koe (58:01.916)
Yeah, no problem.
Todd Geist (58:04.568)
There it is, okay. I'm not sure why I didn't get it the first time. That's interesting. It doesn't seem to have a problem now. Let me just start a new chat.
Todd Geist (58:22.69)
Okay, so what I'm gonna do is I'm just going to paste in this prompt and run this prompt that's basically just saying, hey, there's a FileMaker file connected to Claude. Explore it, tell me what you think it's for.
Ernest Koe (58:42.449)
So that file is open in the background, right? Locally.
Todd Geist (58:44.534)
Yeah, that's this one here. And we saw it's got this little window open for the server connector.
Todd Geist (58:56.726)
Okay, so now it says, I got a file open, CRM. That's the name of this file. It's right down here. It's this file down here. That's the name of the file, and it's just gonna explore it. Now, I'm gonna...
Just allow it to use whatever tools it wants here.
Todd Geist (59:21.112)
So it can read, it can get the scripts, can get value lists, it can get the DDL, which was added for the AI stuff. It can get layouts and the tables that are connected to them, the fields are on the layouts. So now it's just gonna, it's just getting script names. can't read the script data itself at this point, but it can get names. So we'll just see what it comes up with. so the idea here is that what the MCP server does is it...
is it gives, like it's making an entity relationship diagram. So this is an instance of what we were talking about before, which is MCPUI, right? So we have a custom ERD viewer that we built into the MCP ProofKit, or sorry, ProofKit MCP that actually makes a nice UI. And this is why we say sometimes that, again, it's like,
Ernest Koe (59:57.114)
awesome.
Ernest Koe (01:00:00.626)
All right.
Todd Geist (01:00:16.216)
How much of the UI are you going to build into an app and how much are you just going to make available to the agent? So you can chat with it, right? This is just one UI. You can imagine any kind of UI that you can think of building, you can build as part of an MCP server, for example, right? So you can blow this up to full screen. You can drag these things around. You can rearrange them however you want. You you get the whole.
Ernest Koe (01:00:29.777)
It's a little.
Ernest Koe (01:00:40.005)
I think it's so cool that it got the joins right for those keys, know, and the cardinality of it, Guantanamini.
Todd Geist (01:00:43.638)
Yep. Yep. Yep. Yep. It got a whole bunch of stuff. And so let's see what else it told us here. So what it is, it's classic B2B CRM invoicing system, right? Classic, yeah.
Ernest Koe (01:00:56.433)
Classic. It's classic time. The kind of thing a small to mid-sized business would do.
Todd Geist (01:01:05.121)
Yep, yep. it can and it's got tools to actually query the database so it can execute data. It can execute SQL. It does a pretty good job of that and it can execute the data API and because it can execute the data API. If you tell it, it can actually update records right? You can do all this within your chat, right? This is so we're not even building custom code yet. We're just using the MCP server to expose our file maker system to the chat, which.
Ernest Koe (01:01:34.331)
Yeah, this is important. You can already use this MCP server to really just interrogate your database and pull data and understand what customers are and how they're connected, invoices, that kind of reporting stuff.
Todd Geist (01:01:51.276)
Yeah. And in chat can build you simple UIs too. It'll just do it, right? It'll start building things. So you could make, you could prompt it to make a sales chart and it would make you a sales chart. It'll do all that stuff because we've exposed all of these tools to it. and, and so that's just step one is you've got MCP in chat, which means you can do all the things like, for example, that we were doing with proof chat to be clear, like this is like an X. So the difference between this and proof chat.
Ernest Koe (01:01:54.853)
Yeah.
Todd Geist (01:02:19.352)
Proof chat lives inside your file maker file. It's running on an agent. It's running on an LLM and then an agent loop that we built, right? This one is running on the Claude agent, which is frankly, you know, mean, Anthropic is a multi-billion dollar company. They're going to have a better agent than we're going to have a proof chat, just to say. anything else to say about chat there? Anything else we should demo there?
Ernest Koe (01:02:33.893)
is anthropic.
Ernest Koe (01:02:44.773)
Yeah, this, because it's an MCP server, and this should work in Codex, I don't think we've fully tested it yet, but in principle, anything that has MCP support and an agent, basically an agent loop as part of its working process should be able to take advantage of this, right?
Todd Geist (01:02:50.52)
Yes. No.
Todd Geist (01:03:07.534)
That's right. Now, agents have different levels of, or all MCP servers, MCP clients, which coding agents typically are, will have different capabilities. most coding agents do not do UI. So they're not going to give you these beautiful entity relationship diagrams back or whatever else has been programmed into it. That's not going to happen.
And so in terms of the cloud desktop, for example, we have three different experiences in cloud desktop. We have the chat experience, have the cowork, cowork, and then we have code. And so code is the hardcore one, which we're going to jump to in a minute. Cowork is in between and extremely interesting. And Anthropic shipped a bunch of stuff last week, Telegram and Slack integration and projects. It's really great. You can make fully fledged agents with cowork now.
So of the three chat and co-work are do display MCPUI, which is a new standard that both Claude and OpenAI support. It's the same. It's a standard that anybody can support and they do. So this in theory should work in chat GPT, although frankly we just haven't tried it yet. So what else to say about that? So that's chat.
Let's jump over to code and let's make a new thing here. And I'm going to make a new folder.
Todd Geist (01:04:42.242)
CRM demo. I think I have another one, so we'll call it CRM3. Now, when I'm in code, I'm in a new paradigm. The first thing I got to do, so, okay, what's my goal? My goal is I want to make a FileMaker web viewer app. Right? That's my goal. And I've got a file open and I want to just build an app based on that file. And I want to eventually going to embed that right into my FileMaker solution and, you know, do that whole thing. Yes.
Ernest Koe (01:05:10.223)
So the old way, so to speak now, is that maybe you vibe code it, or you write the HTML and CSS and all that in cursor or in cloud. And then you make a bundle, and then you copy it into WebViewer, and then you run your tests on it. And then if it doesn't work, you do the whole thing again, and you copy paste, and you manage that. And then.
Todd Geist (01:05:26.114)
Yes. Yes.
Todd Geist (01:05:32.664)
Yes, yes.
Ernest Koe (01:05:35.311)
You stash the code somewhere and then maybe you want to update it and it's like, okay, do you copy it back down to your computer and then you paste it manually? That's the current story, right? Which is, we've done a bunch of these.
Todd Geist (01:05:44.652)
Yeah. And so one of the, you know, a breakthrough from a few years ago is we got it to where you put a web viewer in your FileMaker app and you'd point the dev server for whatever framework you were using, like Veed or React, Next or Next.js or whatever. And then you could actually see the UI update in your FileMaker file, which was really cool. And you could call the FileMaker scripts and it would all work. The problem is, that browser is embedded in FileMaker.
which means it is not open to all the automation tools that you can do if it's in Chrome or in cloud or whatever. And so again, we want to remove the loops, we want to get people out of those loops as much as possible so the agent can do more exploring and fixing of itself rather than you having to do it.
Ernest Koe (01:06:30.627)
It's also worth mentioning that although this was smoothed out a little bit with quite a lot actually with ProofKit itself, but you had to know which framework to use, what bundler you use, whether it's Vite or something else, is it Next.js in the background or not, is it, do you need node running somewhere and how do you do it? mean, there are lots of like, like set up project details and then.
Todd Geist (01:06:44.514)
Yes.
Ernest Koe (01:06:56.195)
and that's even before you get into things like auth and all that which we may not get to today but there was a lot of different things that had to kind of be in place before you could successfully do a web-based web viewer project, right?
Todd Geist (01:07:09.23)
That's right. You had to understand a lot of stuff about how the web viewer works. We do. Like you could say, we have taste in this. We have a lot of experience in knowing what the happy path is to making web viewer apps work inside of FileMaker. We have shipping apps that are shipped that way that hundreds, if not thousands of people actually use. Well, maybe a thousand might be the high end of it, but it's a lot and it's in heavy, heavy use all the time. That's auto deploy part of our deployment frameworks that we have.
That's all the WebViewer app, the entire thing is WebViewer app living in FileMaker. So we know how to build these things. And so what we've done in this MCP server and inside of ProofKit is we baked in that taste so that you get a sort of big head start. You do not have to go figure this stuff out. You can, you know, you could, you might even find, Claude might even find references to things we've published and eventually get you there. But again, project setup is still really the key. Like if you don't...
get the project set up properly, it's going to struggle. The coding agents will struggle. And so what we've tried to do is make this as simple as possible to get going with ProofKit. That's right. Yeah. So what I've done here is I've selected this folder, CRM demo, which again, you're going to have to do. You need a folder to operate in. It's best just to give Cloud Code a folder upfront.
Ernest Koe (01:08:18.481)
and consistent. think consistency is important in the story. Okay, so here we go.
Todd Geist (01:08:36.14)
and say, this is my folder, and then it will go ahead and operate within that.
Ernest Koe (01:08:40.689)
that's a code base, basically.
Todd Geist (01:08:42.446)
That's your code base. Like this is where I want to put it. So that likely will be the thing that you eventually check into GitHub so you can manage this, you know, using using using Git and all that. But in this case, we're just giving it a folder on my desktop and we're just saying, go ahead. And I have also set this up to bypass permissions, which will it'll make it so I don't have to click as so many, you know, approval approval approval things for all the terminal commands it's going to run. So.
Ernest Koe (01:09:05.041)
prove it all.
Todd Geist (01:09:12.237)
So let's do a prompt here. So let's say...
I have a FileMaker file connected to Claude. I would like to make a FileMaker web viewer app using ProofKit with that file. Can you get me started and set up properly?
Todd Geist (01:09:37.762)
The first thing he's gonna ask me to do is trust the workspace. That's the standard with Cloud Code.
Todd Geist (01:09:48.632)
So this is gonna take probably a while. So we can talk over this as it's going, but just notice what it's doing in the background. It's checking out, it's exploring the situation and now it's gonna run the init command that sets up this project the way that, this is where we've applied our taste, if you will, to the project. And so it's gonna get itself set up properly so that it will run in the way that.
will just make it super easy to go.
Ernest Koe (01:10:19.825)
So it knows how to initialize a proofkit project because the MCP server is connected.
Todd Geist (01:10:27.626)
The MCP server has a project setup tool. And so it's listening for you to say something about set me up a project. And now it's going ahead and doing that. And now like these are other things is we've got this, there's this library out there called 10 stack intent, which actually will automatically install skills, agent skills to the repo based on the code that's already in place. And so it's going ahead and doing all this stuff, setting it up.
setting up the Claude MD, setting up agents, doing all the things that it needs to do to do this.
So this is the stuff that you would have to figure out and tell it how to do. And we've just set it up so the MCP server just tells it how to do. This is another example of instead of like giving you a code base to open up and use, we're just giving the agents the context it needs to do it all itself.
Ernest Koe (01:11:21.905)
tools.
Ernest Koe (01:11:28.997)
Yeah, this is key because the MCP server here is not merely a connector to your file maker file. It's coming with a battery of tools and other things that it needs to kind of bootstrap itself into this process.
Todd Geist (01:11:44.002)
Yeah, so now it's exploring the metadata to figure out what kind of thing we can build out of this.
So here's the files that are available, the tables.
Todd Geist (01:12:04.248)
So proofkit has figured out, the agents figured out that we can connect directly to the FileMaker file and start to generate the TypeScript libraries that automatically connect to your FileMaker file. And TypeScript is one of these other things that's really helpful because it's one of the things that agents are very good at. if types are wrong, if the code is wrong, the agent can quickly and easily determine what's wrong and fix it.
That's why we pretty much don't use JavaScript per se, we use TypeScript always, because it's another way that the agents can self fix. They know how to fix what they're working on here.
Ernest Koe (01:12:44.059)
How's it handling the data connection to the WebViewer app that it's trying to scaffold up now?
Todd Geist (01:12:50.998)
Yeah, which is interesting, right? Because we're not even running it. We don't have a web viewer with this dev server and we don't have the dev server set up here. Let's see what it's doing. So setting up the schema. So it generated the schema for customers, contacts, products and invoices and invoice items. And so it now has, so, okay, this is what's available.
So yeah, let's just do what it's suggesting, which is let's start the dev server and then build out an initial page like a customer list. Let's just see what it does.
That's good.
Yes, go ahead with your idea.
Todd Geist (01:13:42.648)
So one of the things that the MCP server does is it lets you run code in a external browser like Chrome as though it was running inside of a FileMaker web viewer. And what's helpful with that is it can, that means that it can use the embedded browsers that it has. And so eventually,
it's going to, I think, try to open up its embedded browser and get to work on it. We'll see what it does here. But what's so what that means is in the old way, we had to add a web viewer on a layout. We put our dev server URL in there, and then that's how we would write our apps. We would just watch the changes go and it could connect to FileMaker because it's running inside of the web viewer. We've made it possible that any code. That's running in a browser on your machine.
can connect locally, directly to your FileMaker file and make those same calls as though it was running inside of a WebViewer.
Ernest Koe (01:14:49.649)
That's pretty hot.
Todd Geist (01:14:53.346)
So it's got the FM data API documentation. It's got itself a to-do list. It's working through its building up navigation. So this could take a little while. It's going to work through. And eventually, we're going to get something. And we'll see what it comes up with.
Ernest Koe (01:15:09.925)
I mean all this setup used to a lot of time, I mean, to kind of do it manually.
Todd Geist (01:15:14.284)
Yes.
Yes. And it also required experience. Like you had to know what you were doing. And so what we're trying to do here is make it so that it's very easy to get set up with a good, stable, ready-for-production workflow for building web viewer apps. And you can see that...
You can see that it's,
What was I going with that? Production. and then of course the next step we can be able to make full web apps. And that's sort of the next round of this. It'll work kind of the same way. So what's going on there? It kicked open the browser. So it just opened it up. Here's the homepage.
Ernest Koe (01:15:54.161)
There you go, preview.
Todd Geist (01:16:02.104)
And look, you can see, let me make this bigger. Look at it. It's now navigating through. I'm not touching this browser. The agent is scrolling around, looking around, navigating in the web viewer here that's over here. And it's reading data out of my FileMaker database. So it is taking a screenshot. Then it reads the screenshot. And it says, OK, it's working. The customer page is pulling live data from your CRM demo. And it pulled in.
Ernest Koe (01:16:30.737)
It's incredible.
Todd Geist (01:16:32.301)
holding all its stuff. The dev server's running. It's still working. It's still doing other things. We'll just let it go until it's done. But so this is now what we mean when we say the full loop. Once we kicked it off, we've had to allow certain things. You can actually make that even if you want to go crazy. You don't even have to do that and let it run everything. And it says, OK. So now we're in Vibe Coding land, right?
and we can tell it what we want to do. So let's say, let's get rid of that homepage that we have and let's just make the customer list with a drill down to the customer detail.
And I'm purposely not giving a lot of detail. You might have more taste you want to apply to it, but I'm just sort of letting it figure out what it thinks I mean by that and just seeing what it does. But again, now we are in the mode where I can talk to the AI and the AI builds my project. And I don't have to.
micromanage that process. It's the agent's job to implement the code. That's what we're talking about jobs before. I want the agent to have the job of writing the code, testing the code. And when it's done, I want it to have done a bunch of tests and figured out how to figure it out that yes, it actually completed the task that I wanted it to go, that I wanted it to do.
Ernest Koe (01:18:04.721)
I'm sure this is a gory technical detail, but I think file maker developers listening to this may be curious how we're fetching the data from file makers. Is execute data API? Is it SQL?
Todd Geist (01:18:21.378)
Yeah, it's all execute data API. The magic, the thing that the MCP server does is it bridges those calls straight from any browser to FileMaker. And that's kind of how that's working.
Todd Geist (01:18:39.672)
So it's showing a list of card views, which is a little goofy. Maybe what we'll do is tell it to make a table view.
Todd Geist (01:18:57.154)
But you can click on it and you can see now look, it's got detail. So it interpreted my...
my idea as a card view instead of a list. But we could prompt it, we could tell it to do whatever we want at this point and it would keep going. And we could even tell it to make editable things. So we could say, the name of the company editable. And it would figure out how to do that. And it would write the file maker code, the execute data API code to edit that and to make that all happen.
Ernest Koe (01:19:30.583)
That's actually a non-trivial thing, right? Because we take that for granted in FileMaker, and that's not always the easiest experience with web code in FileMaker.
Todd Geist (01:19:40.75)
Yeah, yeah. So that's all going to work. Now, the interesting thing is this is already useful. You could imagine that you have a particular view of the data you want in your FileMaker database. And you want the UI that you want in the FileMaker database. You don't actually care if anybody else has that same UI. You can use Cloud Code to write your own custom UI to a FileMaker database. Never deploy it anywhere.
just have it sitting in your cloud code. You come over to your, you open up this particular thing, you hit preview, and this is your custom UI. And it can update records. You can tell it to basically build any kind of UI you want, including writing back and making edits. You can do dashboards, edit views. You could write skills into your file that would tell it how to run certain things like.
Okay, I need to send a new email to this customer and the agent will just pick that up and do it. you right here, we're looking at an agent over on this side is the agent on this side is the UI that the agent is building in real time for you. You could do things like set up this, you could set up cron jobs to run inside of this agent that we're building to do certain things. And like that time tracking thing that I talked about before, I could just open this up in the morning. It could have my time sheets ready to review right here in my UI.
Ernest Koe (01:21:08.699)
So as it is right now, does it know anything about scripts and can it call scripts that are inside the existing file maker file? So you could load up all your business logic and your scripts like you normally do and then it could just fire those off as part of the process. Let's say when I make a customer record, I need to get two approvals and it fires an email, but if those are already script calls that you've wired up, it could just pull those, right?
Todd Geist (01:21:08.824)
So.
Todd Geist (01:21:14.058)
It can you can tell it to call particular scripts too. Yeah. Yeah, it can do that.
Todd Geist (01:21:36.014)
That's right. That's right. I can just do it. It can read the script name so it can actually validate and call the right script. So it can do all that. It can get value lists. It can do it can value list tables. Basically every bit of metadata that made sense to get it can get. And so that just helps it write better code because it knows what it's writing against. So you could choose to leave this directly in your file and just use it yourself or
you could choose to share it with your team. so, okay, I want to share this with everybody who has access to this file. So let's deploy this HTML to the FileMaker file so that it will work embedded inside the FileMaker UI without having to run Claude.
Todd Geist (01:22:34.574)
So now we have a tool which knows how to build this app into a single HTML bundle and install it into the FileMaker file. So that's what it's going to do. It's running a build. You can see here.
Todd Geist (01:22:52.302)
Build successful, all done.
Todd Geist (01:22:58.158)
and it's deploying it. See if it gets that done.
Todd Geist (01:23:07.768)
file.
Todd Geist (01:23:21.496)
I can see if it finished already. Let's go look at ProofKit apps. Open. And it looks like it did.
now it's trying to deploy. Okay, let's see.
Todd Geist (01:23:41.454)
There it is. There it is, it's in your file.
Ernest Koe (01:23:43.963)
freaking amazing.
Todd Geist (01:23:48.502)
Okay, one more step. I've developed all this on my computer. It looks great. I've got this file. I want to share it with the world. What do I do next? Well, one of the tools we have in Cloud Code is...
Look at the connectors, manage connectors.
Todd Geist (01:24:15.086)
Proofkit.
Todd Geist (01:24:22.626)
to call.
Todd Geist (01:24:30.85)
I wonder if I have the wrong, let's just see. There's a tool in here, maybe it's a different name. Deploy HTML is not it. I got metadata.
Ernest Koe (01:24:30.875)
Not in this version.
Todd Geist (01:24:42.978)
Huh, it looks like it does not have the tool that I was expecting. I think I know why. Yeah, I'll just say, I'll just talk it through at this point. What we have is a deploy to automatic feature built in. So it'll deploy right to automatic. And the reason is I didn't put my API key into the project. We'll just skip that for now. But the idea is that you can automatically deploy to automatic.
Even if you don't have a server, can deploy. We will spin you up a server and deploy it and that file is immediately available to you to share with anybody in the world. then if you don't do anything with it or if you don't decide to give us a credit card, we'll just destroy it after a certain number of days. But it's all built in and I'm sorry I don't have that demo. I have a video of it. Maybe we'll post that in the show notes of it working.
it will just deploy it automatic and you have your file. So you can start with a local file on your FileMaker's desktop. You can build it, do whatever you want. You can make an HTML, beautiful UI connected to all your FileMaker data. And then when you're ready to share it, can deploy it to the world. So that's what we've been working on. It's pretty exciting.
Ernest Koe (01:26:03.567)
That's pretty amazing. This is really, really cool. Can't wait to get this out. What's your thinking, Todd? I mean, we are...
Todd Geist (01:26:13.464)
Well, right now it's in private internal review. So we're going to get whatever kinks are left like that. The tool is turned off when I don't have the key installed properly, and I just didn't for the demo. Obviously, we want to make sure that you can deploy to our platform in a secure way. And so that's one of the last wrinkles that we had to figure out.
Ernest Koe (01:26:13.521)
I think right now we're using internally.
Todd Geist (01:26:39.528)
I don't think it's going to be too long. We're just going to probably do a couple of weeks on it and then we will figure out how to make it available to everybody, which we haven't quite figured out, but that's where we're going. And I think that the key thing there, I what we demonstrated is the value of removing the person from the loop or as much as possible and making it so the agents can work.
And so we know that agents can work quite well with FileMaker Web Viewers. There's nothing that prevents an agent from just doing its whole agentic loop, setting up an app and working on that app. And then we just have to layer the right tooling in there and it works.
Ernest Koe (01:27:30.417)
I think this is, I we've been talking about this, but certainly we feel like this is going to just revolutionize the way we work in FileMaker. I mean, we're treating FileMaker as a first class app container and database backend. And it's actually really cool because that separation, sort of front-end versus backend, I mean, when you build a web app, if you're using Node as a server,
I mean, have that distinction. You have a Next.js app running in Vercel and whatnot. There is a backend, your secrets, and your server-side stuff is being handled. But the FileMaker file becomes a really credible place where you can deploy all this cool web code without really doing much more than writing it with your agent. And then you don't have to worry about all that other layer of stuff, the server, the infra.
Security is handled because it's just going through the FileMaker security layer. So whoever has permissions to that layout and whoever has access to those fields or scripts that you are tying to, that still stays the same. You don't have to re-architect and redo all of that. So I can imagine this being a really sensible path to update, upgrade a lot of existing FileMaker apps, take existing layouts, modernize it, and just make it really performant within a web viewer.
Todd Geist (01:28:56.396)
I expect you to see a lot of people making new apps because one of the interesting things about agents is there's a lot of it's done on your computer, right? So why not just build a little agent, build like we did, we built a little, bunch of little agent UIs. You can just put them in a file maker file. The advantage is it's running on your computer. It's just yours. It's database. So you've got all the database stuff in it, but your agent can operate with it. It can read data out of it. It can write data to it. It can update UIs for you.
Ernest Koe (01:28:59.537)
Yeah.
Todd Geist (01:29:23.788)
So it's actually a really good little database in terms of like self-contained, very easy to understand for doing local agentic development. And then it also can be deployed on a server. So if you think about like what has changed here, we used to think of FileMaker as being the fastest way to build UI and for business operations. And that's just not true anymore. It's just, you know, using native FileMaker layouts. just, you have to really just know that you got to
absorb that in your heart, because it's just not true. It's way faster to do it with agents. So once you get over that, then it's just like, this is not a problem. This is easy. You still have to write your scripts by hand. We've got some older ideas, which we can try to, which we'll talk about maybe later about how we can improve some of that. But also we're really, we're using this as a way to explain and show to Clarice what we mean by these things that we're talking about. Like,
I think Clarus believes that they need to build an entire agentic coding UI in their application. And what we're trying to say is, no, you do not. You need to build the hooks that the agentic coding environments already use. That's a key distinction.
Ernest Koe (01:30:34.085)
I would say, yeah, I would say I don't have Claire's things that way, but I certainly see a lot of opinions about what Claire's needs to do, which is exactly that. I think a lot of people are saying, and I have a lot of respect for a lot of devs who are saying this, because I get it. We want to be able to compete in agentic development space, and we want vibe coding to come to FileMaker in some way.
Todd Geist (01:30:43.852)
Yeah, maybe that's a better way of saying it. Yeah.
Ernest Koe (01:31:01.137)
have a file maker become DIDE, where you're making layouts, making scripts, making all the rest. But I think our strong opinion here is that we don't need to wait for any of that, because A, it's already very, very good outside. And it will always be, I think, better, given the agent harnesses that Claude and Codex are putting together. I mean, that's just an incredible coding environment, programming environment.
And it's incredibly rich and it's already where you are working, which is the most important thing. It's already where you're building things in the world. And we think that ultimately it would be nice to be able to agentically modify and create scripts and schema and structure and whatnot. But as the first step to making this first class agentic platform, we should just start here and make these layouts a non-issue.
Todd Geist (01:31:55.586)
Yeah, just make web viewers the way to build apps and do what we can to make that even better. And there's more that we can do. Yeah, but I think like, like to me, if I could get to where I could script and update tables with my agents, that's gotta be above 90 % of all the code that you write, right? Like the other stuff, maybe custom functions too. That would be the other thing. But everything else is like you set up your security privileges. You don't change those all the time.
Ernest Koe (01:31:56.219)
that will modernize everything.
That's more than we can do.
Todd Geist (01:32:24.846)
You know, the other things that aren't that valueless is a few things like, if you could just do scripts and tables, that would be, it's got to be 90 % of the code as you write would be in those areas.
Ernest Koe (01:32:35.281)
And I think it's worth saying that we're coming to this not from some, I don't know, I think we're coming to this with some informed, from some lived experience and some informed understanding of what it takes to do it the other way. mean, when we wrote ProofChat as a, basically, an in-file maker agent, I think two things became very, clear in that process, like one,
Yeah, the amount of effort to really make that into a world-class, do-everything agent is non-trivial. Doable, but non-trivial. And you have to pick your battles at some point. I think for specific use cases and for narrower problems that you want to solve where chat is still a primary UI and you want to do that, that's okay. But we've also done things like Vibex, that you prototype, you're building scripts and FileMaker.
And it just seems like in order for that to be a fluid experience, we want to just get past the old copy-pasta modality. We've got to break through. We need APIs and SDKs that we can actually leverage in an agentic way. So really, it's not that we don't think those ideas are interesting. We've tried them all. I think it's more like,
Todd Geist (01:33:43.66)
Yeah, yeah, for sure.
Ernest Koe (01:34:01.414)
This is a clear, mean this unlocks so many things out of the box. It gives you a development surface that we can iterate on much more quickly than anything else that we can do in FileMaker today. We can bring on online new components, so we can open this up to the whole FileMaker ecosystem. We can make the layout design surface a non-issue. It's still useful and relevant for all kinds of things, like admin layouts and things like that.
But it doesn't have to do all the heavy work of making your app experience number one anymore. That can now be shifted towards a place where you can have a lot more control and do it faster and better and all that sense. So I think for me, go ahead.
Todd Geist (01:34:46.05)
Yeah, I'd like to say one more thing about that too, if I could. So, you know, what if, think now FileMaker itself, the app is not free. But what if it was? What if FileMaker was just free and it was on your computer? The other thing that's happening right now, that's, you again, like how do you get people to understand and to know what you can do with these apps? So here's an example.
Ernest Koe (01:35:03.441)
100 %
Todd Geist (01:35:18.766)
So this is inside of Claude, there is a, you can go and you can say, give me connectors. And there's all these connectors from all these companies. Wouldn't it be great if there was a Clarus one here?
If there's a, cause every coding environment has a marketplace cursor has it. Codex has it. Claude has it. What if this was just, there's a Clarus file maker plugin and you can just install that. And that's how you get this MCP server that we're, that we're talking about doing. that's how you get it. And then you've already got file maker because it's, it's free. I think this is the, this is, and again, people who are coming to this agentic stuff soup, now maybe they,
play with FileMaker once and a few times in the years past, or they've heard of it, or they know something about it, and it's something they feel they understand, or at least they feel they can deal with. How many people are gonna pick up FileMaker again, if it's in this marketplace? Or how many places that have FileMaker, where they have licenses already, will they get extended? Will they get extensions, new seats, new licenses, scale, because...
There's a Clarus marketplace, you know, there's a Clarus file maker connector here in the marketplace. I think it's compelling.
Ernest Koe (01:36:44.945)
Yeah, I talked to somebody recently. I think it was John Luke out in...
Canada, well-respected, long-time dev. And he made a comment that I thought was really spot on, and that is, AI is doing incredible things for the development world, just to paraphrase things. And he imagines that's where he's spending a lot of his time, not most of his time, building things. But there are still separations of concerns and problems that he'd rather not have to worry about and deal with. Like, deployment is still a pain.
And it's a pain, not because for cell is difficult and super bass is difficult. Those things are ostensibly on your own, not really difficult once you have AI in the mix. The problem is with more AI, you get actually more complexity. Like it gets back to this idea that you're creating jobs for yourself every time you choose to touch a layer that you want to affect, right?
His thing was, well, I don't want my job to be like managing infra. I don't want my job to be managing servers. I don't want my job to be managing how the database performs and the security layer around it and all that. And I think that insight speaks to what problem this actually solves. So you can still do your problem solving, vibe coding, agentic development in cloud or codecs or whatever.
But now you have a development target, a deployment target, where that entire layer doesn't have to be your job. It's whoever's job already that is to manage that continues to stay the same. And you're drastically reducing the complexity surface area so that you can focus on actually building rather than maintaining and serving and hosting.
Todd Geist (01:38:40.238)
Yeah, I mean, if you have FileMaker, you can agentically code it and do some really interesting things with just what we've shown today. Like, we don't even have to go farther than what we've shown today, and it's already really cool because your alternatives with agentic coding are you're to have to deal with SQLite. Again, not a hard thing, actually a great database, but you've never seen it before. Now you have to take on a new responsibility and you already have FileMaker, you already know how to use it. Just make a new file.
put it in a folder, open it up, target it with ProofKit MCP, and start building. When you're ready to share, share. No friction. And you're now building things that look great, that look really, really good, and are closer to the experience that people expect when they think about modern UI and applications. And you can do a whole lot. And there's a lot more to...
Ernest Koe (01:39:16.721)
Complexity is a killer. Yeah.
Todd Geist (01:39:36.45)
talk about like how you can adopt some like schema list designs with your FileMaker table. So you don't need to have all your data in every field, know, every field spelled out. You can use JSON objects as data instead. Like a lot of ways in which the AI is again, are really good at iterating on top of that, that you can do right within FileMaker. So if FileMaker was the way to build rapid UI and it's not, it's no, and you know, and
and business workflows. It's no longer that in terms of like, in terms of this way faster ways to build out the UI and the workflows that you want, but it's still, it is actually a great deployment target. It is the container, the app container that is really, really, really good. And you already know how to use it. So.
Ernest Koe (01:40:22.865)
Yeah. Yeah. I also think about performance and some of the other, think, mature file maker systems tend to go through this evolution cycle where you start simple and then you get more more complex. Again, complexity kills. And what suffers is performance because the layouts now have to do a lot of work and you have lots of relationships in your graph and all that.
Todd Geist (01:40:25.878)
It's that. It takes care of the security layer for you and all the other stuff.
Ernest Koe (01:40:49.419)
And one way to solve that is to have more performance and analytical tools to figure out how you optimize. The other way you solve it is to just remove it, kind of delete it.
Todd Geist (01:40:59.566)
Get rid of all those layouts and build them in a new way that is not going to be so difficult. mean, we all know where FileMaker Performance bottlenecks come from. It's almost always UI. It's people trying to, know, sum a bunch of records through a filtered portal, for example, know, things like that. None of that's an issue with web-based stuff, you know, especially if we can get some of these other...
Ernest Koe (01:41:02.213)
Right.
Todd Geist (01:41:29.134)
some of these other rough edges polished off, it's just not a problem.
So I think we've been on for a while. I don't know, this thing's going to be well over an hour by the time it gets edited down. We didn't get to talk about some of the other things. We'll save those for next week maybe or next time. But we'd love to know what you think of this stuff and sort of the general discussion, but also what you think of Proof Kit MCP. drop us a line, let us know if this is something that...
you think is worthwhile and tell Clarice too, if you agree with us. I mean, we're doing what we can and we're working with what we have and we're working with Clarice and they're very receptive. But anything that we can do to help sort of get this message across, if you agree with it, if you buy it, if you believe it, then help spread the word. Because I think this is really important. And yeah, so.
Ernest Koe (01:42:09.233)
Well, please don't be shy. Definitely tell us because we would love to hear from you and subscribe.
Todd Geist (01:42:33.614)
and super fun, makes FileMaker fun again.
Ernest Koe (01:42:37.553)
I the last thing I might maybe say about this is that I'm just so excited that there's so much energy around AI and how we apply it to FileMaker. I see a lot of different projects getting launched, trying to bring AI into FileMaker and all that. I certainly don't, I think there's going to be a sort of an explosion of different approaches to
making FileMaker a better citizen in the whole agentic AI development process. Todd and I have a premise based on what agentic development means and how that shapes our thinking. And that's how we're talking about this stuff. But hey, if you're building AI stuff and AI tools for FileMaker, please share that with us. And if you want to come on the podcast and talk about it, we'd love to hear from you. That would be.
That's all I think on mission in terms of making our work and the space all around just better.
Todd Geist (01:43:41.186)
Yeah, I should say like the MCP server exists today. There's about half of it is really strong opinions and the other half is just tools that are given to the agent to explore a file maker file. So we think in the future that those opinions can be much more malleable. Right now we're focusing very much on making sure it works. And so we're really, we're expressing our opinions quite strongly. That might change though. It might loosen up and you...
if you have a slightly different way of setting up a project that still works. We'd love to hear about that so that we can eventually expand out and allow you to allow people to have their own taste so they can apply to this. So I think that's it for this week. And I don't know, we're gonna try to do these things much more often. I don't know. It was just so much fun to be had programming. It's little hard to take some time off and actually talk about this stuff.
Ernest Koe (01:44:34.085)
You
Todd Geist (01:44:38.162)
do our best. Let us know if you want to hear more and that will encourage us to do more. So thanks very much. Bye everybody.
Ernest Koe (01:44:38.576)
sure.
Ernest Koe (01:44:43.473)
All right. See ya.
