Designing for an executive function that is not always there

I run a business I could not run without the software I built for it. The reason has very little to do with efficiency. I am autistic and ADHD, diagnosed at 37 after sixteen years of secondary teaching and a burnout that ended that career in 2021, so my executive function is not reliably available and some weeks it is largely absent. 

In practice that is ordinary and expensive. I make a commitment, then three weeks later somebody is waiting on it and I have no memory of making it. On the weeks the function is absent, opening the inbox is itself a decision. Deciding is the exact thing that has gone. 

I stopped trying to repair my own executive function and built an external one instead. It holds what a project manager would otherwise hold for me, which is what is in flight, what is waiting on another person and what I agreed to and then forgot. Two things I have built and shipped sit on top of that system. Jenny Wren is an AI coaching companion my members reach through Telegram, while Burnout Buddy is a web app for people in burnout. 

The AI productivity tooling I have used previously all starts from the same place, because it assumes an executive system that is present and sets out to make it faster. Mine assumes the function is intermittent and sets out to do the work while the function is missing. Those two briefs produce very different software. The difference does not show until you look at what happens when the user disappears. 

The gap has a literature, although it sits outside the AI industry. The W3C’s cognitive accessibility guidance observes that accessibility work has traditionally concentrated on vision, hearing and mobility, with memory and attention a long way behind. Research on autistic adults from King’s College London and the Maudsley found executive function difficulties that were disabling in everyday life, even though more than a third of the same group showed no impairment on the measures used. So the constraint is real and it varies between people, and my own experience is that it also varies within a person from one week to the next, which is the version almost no tool is built for. 

That design brief is what the rest of this piece is about: what breaks when a tool assumes you will turn up, what a tool has to do differently when it assumes you might not, why that has only just become buildable and what brief comes out of it. 

What breaks when the tool assumes you will turn up 

A tool built on the first assumption falls over almost immediately. Notifications pile up, the streak breaks and the interface fills with red until opening it becomes a thing to be avoided. By then the tool has become evidence of failure, which is an efficient way to lose a user permanently. 

It did nothing wrong by its own brief. Summarise this thread, draft this reply, pull the actions out of that meeting: every one of those is useful and every one of them assumes somebody is there to read the output and decide what happens next. Most of the time most users are. The tool was designed for them. 

What a tool has to do when it assumes you might not 

A tool built on the second assumption has to expect the absence and still be standing on the return. That means it holds state so the person does not have to, and it reports that state without being asked, because asking is itself an executive function task and one of the first to go. The cost of coming back has to be close to zero. A re-entry that needs ten minutes of orientation will not happen at all on the day capacity is lowest. 

That rules out every mechanism that penalises a gap, so streaks, escalating reminder tones and progress bars that reset are all off the table however well they work for a person who was going to come back anyway. It also raises the stakes on every inference the system makes on its own, because a person who has stopped keeping the information in their own head has no way of catching it when it is wrong. The honest answer there is to keep those inferences few and show the working. 

The hardest case is silence. Four days of nothing can mean a holiday or a deadline elsewhere or a shutdown, and those three want very different responses from the software. No amount of inference settles that. The system has to ask, in a way that is free to ignore. 

Why this only became buildable recently 

Not long ago a system like this was not worth building because it still needed the user to do the structuring. Most project tools ask you to name a task, choose a project, set a due date and pick a status, which is four separate operations before anything has been recorded. On the days the function is absent that form is exactly where the tool stops being used. 

What changed is that a language model will accept mess. It will take a half finished sentence or a forwarded email or a voice note that circles the point three times before reaching it, then structure it afterwards. Moving the structuring to after capture instead of making it a condition of capture is the whole difference between a tool that works on good days and one that works on the days it is needed most. 

I am not an engineer. I wrote and shipped this myself using AI coding tools, with no development team and no funding, and I suspect that route is closer to where many readers are heading than another enterprise deployment case study. What it changed was who held the pen. The person living with the constraint wrote the software for it, so an assumption like the user will come back tomorrow could not stay invisible for long. 

The brief that comes out of this 

There is a real risk in outsourcing your own capacity to a system you then cannot work without. I have felt it. When the system is unavailable I am worse than I would have been without it, because none of it lives in my own head any more. I decided that trade was worth making and I made it with my eyes open. 

The rule I settled on is to automate everything except being human. In practice that means anything that is only a memory problem goes to the machine: what I agreed to, what is waiting and what comes next. Anything that requires me to decide what I think stays with me, and I do not let the software make that decision on my behalf.

So the outcome is a brief, and any team building productivity tools can use it. Assume the executive function is intermittent. Hold state so the person does not have to, report it without being asked and make coming back free. Then test the result the only way that counts, which is to take the user away for four days and see whether the thing is still standing when they get back. 

References 

W3C Cognitive and Learning Disabilities Accessibility Task Force, Making Content Usable for People with Cognitive and Learning Disabilities. https://www.w3.org/TR/coga-usable/ 

Executive Function: Cognition and Behaviour in Adults with Autism Spectrum Disorders, Journal of Autism and Developmental Disorders. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6751156/