AILeaving Kondra, and an Idea That Stuck
I left Kondra Systems last month, after close to four years. It was a good place to grow up professionally and I’m grateful for it.
Rather than write a farewell post, I want to write about a thing we explored and didn’t build, because I’ve thought about it more since leaving than I did while I was there.
The Idea
It came from David Vogt, which won’t surprise anyone who has met him. He has a habit of describing something that sounds obvious and then you realise nobody has done it.
The idea was an assistant that manages your time. Not a calendar. Not a to-do list. Something you could talk to in ordinary language, that understood your commitments, your preferences, and your actual constraints, and did the tedious work of arranging your week.
“Find an hour with the finance team this week, not on Friday, and not before ten.”
That sentence contains a startling amount of unstated context. It knows who the finance team is. It knows what an hour with them means. It knows Friday is bad, which it can only know if it knows your Fridays. It knows that ten in the morning is implied. It knows which of your existing commitments are movable and which are not, which is a judgement even your colleagues get wrong.
When David first described it, my honest reaction was that it was very futuristic. I still think that, and I want to be precise about why, because I don’t think it’s the part people assume.
Why It’s Hard, and It Isn’t the AI
The obvious objection is that understanding language is hard. It is. But that’s the part I’d expect to improve steadily, and it has been improving steadily.
The parts that worried me are more mundane and, I think, more binding.
People are mobile now, and that changes everything. When I started this blog four years ago, an assistant like this would have been something you used at a desk. That’s over. The interaction has to happen on a phone, on a train, on a bad connection, in a spare thirty seconds between two meetings. Which means the latency budget is brutal and the interface has to be nearly frictionless. An assistant that takes four exchanges to book a meeting is slower than doing it yourself, and people will simply stop using it. There’s no partial credit here.
The servers are the real cost. Doing this well means holding a model of a person’s schedule, preferences, relationships, and history, and reasoning over it in real time, for every user, continuously. Not on request. Continuously, because the value is in it noticing that your Tuesday just collapsed and offering to fix it before you’ve looked.
That’s an enormous amount of state and an enormous amount of computation per user, and unlike search or advertising there’s no obvious way to amortise it across people. Each user’s problem is entirely their own. I spent some time trying to sketch what that infrastructure would cost per user per month and I couldn’t get to a number that a consumer would pay.
“The algorithms will arrive on their own schedule. The thing that decides whether this is a product is whether serving one person’s calendar costs pennies or pounds, and right now it’s pounds.” — Sameer Gupta
And the algorithms aren’t there yet. Scheduling is a constrained optimisation over soft, unstated, personal preferences that shift constantly and that the person themselves couldn’t articulate if you asked. Half of what makes a calendar good is knowing which meeting you’d resent, and nobody writes that down.
Where I Think This Goes
I don’t think the idea was wrong. I think it was early, and I’ve been watching the pieces arrive.
The assistants that shipped in the last few years handle single commands well and context poorly. Microsoft announced Cortana last month and the pitch is explicitly about a personal assistant that learns your preferences over time, which is a step toward the harder version. A handful of startups are attacking the calendar problem directly.
None of them, as far as I can tell, are doing the thing David described, which requires holding a genuine model of a person rather than answering a question.
The things that would have to become true:
- Cost per user has to fall by a lot. Which historically it does, so this may be the least worrying constraint. It’s just a matter of when.
- Language understanding has to handle implication, not just instruction. There’s interesting work happening here and it’s moving faster than I expected two years ago.
- Somebody has to solve the trust problem. This assistant needs your calendar, your email, your contacts, and your habits. That’s the most intimate dataset most people have. I notice I have no idea who I’d be comfortable handing it to, and I’m someone who writes about this for fun.
What I Take From It
Two things, and they’re the reason I’m writing this rather than a leaving note.
The first is that I’ve now watched a genuinely good idea fail to become a product for reasons that had nothing to do with whether it was a good idea. It was economics and infrastructure. I suspect that’s the ordinary case rather than the exception, and I’d been assuming the opposite.
The second is that I’ve started paying much closer attention to the cost side of these systems. When I wrote about how ad systems work a couple of years ago, the thing that struck me was that the constraint was a latency budget rather than the model. This is the same lesson in a different shape. The interesting engineering isn’t making it work. It’s making it work at a price somebody will pay.
Final Thoughts
Thank you to David and to everyone at Kondra. I arrived not knowing very much and I’m leaving knowing slightly more, which is about the most anyone can ask of four years.
I’m going to spend the next while reading, writing here more often, and working out what I want to do next.
And I still think somebody is going to build the time assistant. I’d guess five years, maybe ten. I’d like to be wrong in the fast direction.