"We don't know, let's try it": Tufty's first outing

Let's give it a go and see

In June we attended the InfoSol Inc “IBIS” conference in Arizona, and for the first time people outside the core team got to see Tufty, the new AI agent inside Squirrel365.

Demoing something new to a room of customers is always a bit of a moment. You've lived with it for months, you know it’s rough edges, and you have no idea whether the thing that excites you internally will land with the people who actually use the product. The reception was better than we hoped.

What resonated most was the philosophy behind it:

“Tufty works with you, not for you.”

Tufty is an assistant sitting inside Squirrel365 helping you build content, keeping you in the driving seat rather than replacing you. You stay in control of the project. Tufty does the legwork.

How Tufty works

Under the hood, we've done a few things. We've given AI visibility of the components available in Squirrel365, so it knows what exists. We've built tooling that lets it configure those components. We've given it the ability to tell Squirrel where to place them on the canvas. And we've made Tufty aware of your project and spreadsheet, so it can work with what you've already built rather than only starting from a blank canvas. If you've got an existing dashboard, Tufty can understand it, extend it, and help you improve it.

I've been describing this as a Lego approach. We've created all the blocks, and the LLM works out how to put them together into the shape or model you're after. Ask for a KPI tile for your dashboard and Tufty picks the right components, configures them, and lays them out. Ask for something we've never seen before, and it does exactly the same thing with the same blocks.

Why this is different from traditional development

In traditional development, you build features and capabilities explicitly. If a product can troubleshoot a dashboard, it's because someone wrote a troubleshooting feature. You know exactly how it works, why it exists, and what the application can and can't do, because you defined all of it up front.

The Lego approach flips that. We've created the blocks, but we don't fully know how the AI will use them. The capabilities of the system aren't a fixed list we wrote down. They emerge from what the AI can figure out to do with the tools it has. That's an unusual position for a development team to be in, and it took some getting used to. It also turned out to be the most interesting part of the whole conference.

The question we kept getting

Customers kept asking variations of the same question: "Can Tufty do this?"

The honest answer, every time, was "We don't know. Let's try it and see."

That's not an answer you would normally give about your own product. But with an agent built this way, it's the only honest one. We hadn't written a feature list that covered every possibility, because there isn't one.

One example: someone asked whether Tufty could help troubleshoot a dashboard that isn't working correctly. We'd never tested that. But looking at the blocks Tufty has access to, it seemed possible. So, we deliberately broke a model, live, and asked Tufty why it wasn't working.

It correctly explained what was wrong. Then it fixed it.

We ran this experiment several times over the week with different "can Tufty do this" questions, live, in front of the people asking them. Each time, Tufty managed the task. Nobody on our team had built dashboard troubleshooting, or any of the other things people asked for. We built the blocks, and Tufty worked out the rest.