AI as Accessibility: One-Click Assistant Restores Executive Function for Neurodivergent Workers

When your brain works differently, AI isn’t a luxury, it’s accessibility

He used to lose two to three follow‑ups per week. Today he reports zero dropped follow‑ups in the past month, and he starts his day with two words: “Run scan.”

Note: This is a detailed single‑person case study, not peer‑reviewed evidence. The outcomes described are Andrew Johnston’s self‑reported experience and should be read as an illustrative example rather than a general guarantee.

Andrew Johnston, a partner solutions architect at AWS with more than 30 years in IT, built an AI‑driven workflow assistant to compensate for executive‑function gaps caused by his AuDHD (co‑occurring autism and ADHD). What began as a productivity hack reads as accessibility tooling, because the assistant reduces the invisible, repetitive cognitive labor that makes work harder for many neurodivergent professionals.

Why this matters

Executive function, planning, prioritizing, initiating tasks and holding context in working memory, is where many neurodivergent people pay a steep price. A Birkbeck, University of London study estimates approximately 15-20 percent of UK adults are neurodivergent, a range that reflects different definitions and conditions included.

Johnston says organization and initiation cost him “10 times the cognitive energy a neurotypical brain expends.” That is his personal estimate and is presented as such. Clinically, the pattern fits common descriptions of ADHD and autism: initiation and working memory can consume disproportionate cognitive resources. If an assistant can take those predictable burdens off your plate, it stops being just efficiency and becomes removing a structural barrier to participation.

“If you need AI to manage your executive function, that’s accessibility. Full stop.”, Andrew Johnston

How it feels, the user story

In practice, each morning Johnston authenticates, clicks “Run scan, ” and the assistant triages his inbox, surfaces a short list of action items, moves tasks on his Asana board, and logs context so he doesn’t have to keep everything in his head. That tiny start removes the hardest moment, initiation, and hands him a curated working set.

Practical anatomy of the system

Technically, Johnston combined a persistent desktop assistant interface (a tool he calls Quick), model inference via Amazon Bedrock, and a small custom orchestration layer he built (a Model Context Protocol, or MCP, server implemented with Kiro tooling). Connectors link the MCP to Outlook (email and calendar) and Asana (task state). The MCP reads human‑editable decision rules (markdown) each session so edits take effect immediately without redeploying code.

Key architectural components (plain English):

Interface: a persistent conversational assistant on the desktop that stores context and runs the daily start command.
Model backend: Bedrock supplies foundation‑model reasoning for summaries and context‑aware prompts.
Deterministic skills: scripted automations (not freeform generative outputs) handle repeatable tasks like moving Asana items or generating short emails.
Rules layer: human‑readable markdown files encode priority heuristics the assistant reads each session.

Important caveat, single‑person case study

The performance numbers and behavioral claims below are Johnston’s self‑recorded outcomes, not independent validations. They illustrate what one person built and measured.
Product names such as Quick, MCP and Kiro are referenced as Johnston used them; MCP appears to be a custom server pattern and Kiro an IDE he used. These may be internal or bespoke components rather than off‑the‑shelf standards.
Before adopting similar tools, enterprises must answer security, privacy and governance questions (see checklist below). The author notes security controls exist but does not provide detailed system‑level documentation in the account shared here.

Concrete examples: rules, skills and results

Johnston stores decision logic in markdown so heuristics are visible and editable. These are not opaque prompt injections; they’re explicit rules that anyone using the system can read and tweak.

“Do First” means someone external is actively waiting AND I can act right now AND it’s time‑bound. If any of those conditions aren’t true, automatically demote., Andrew Johnston

“Urgent” isn’t a feeling. For me it means: Someone external is waiting, I can act right now, and there’s a deadline within 48 hours., Andrew Johnston

Representative deterministic skills used:

Email formatting and controlled sends (rule decides draft, send, or schedule).
Context logging, attach concise session notes to the relevant Asana task or email thread so the assistant and the user share state.
End‑of‑day summaries that surface deferred items and next‑day candidates.
Task state management in Asana: backlog → today → follow‑up transitions based on rules and calendar context.

Johnston reports inbox scans now take about 6-13 minutes versus “over 45 minutes” manually before the assistant, and his longest sustained workflow streak is “by a factor of four” longer than any prior streak. He also reports “zero dropped follow‑ups in the past month, ” where previously he estimates losing 2-3 per week. These figures come from his informal logs and are presented here as illustrative outcomes rather than rigorously benchmarked metrics.

“building a system that maintains itself.”, Andrew Johnston

The single‑action start principle

Initiation, making the decision to open a tool and use it, is the friction that kills adoption. Johnston’s core design rule is to reduce initiation to a single near‑reflex action. Authenticate once, click “Run scan, ” and deterministic rules and skills do the rest. That single‑action principle is the accessibility move: shave the top cognitive cost so the tool survives long enough to be helpful.

Security, privacy and governance, concrete checklist

Any system that reads email, calendar and tasks raises real legal and compliance questions. Ask these concrete questions before piloting:

Where is conversation memory hosted? Local desktop, cloud tenant, or third‑party model provider?
Is data encrypted at rest and in transit? Who controls encryption keys?
Are prompts, context or email body text sent to external model providers and retained in logs?
What are retention windows for assistant memory and audit logs? Can users export or delete their memory?
Who can authorize the assistant to act (send mail, change deadlines)? Implement role‑based access control and human‑confirmation thresholds for actions that affect others.
Is there an immutable audit trail for each automated action and an easy recovery/remediation process for errors?
Do vendor contracts include data‑residency clauses, processor‑controller responsibilities, and breach notification terms aligned with GDPR or local law?

Design checklist if you want to build something similar

Make the start single‑action. If it takes more than one decisive step, it will be skipped.
Encode heuristics in human‑readable markdown so owners can edit rules without redeploying code.
Keep deterministic code paths for high‑risk actions (sending mail, moving tasks) and reserve generative models for context, summaries and suggestions.
Persist working memory but provide clear controls for deletion, export and auditing.
Design human‑in‑the‑loop confirmations for actions that materially affect other people’s schedules or communications.
Document precisely how you measure success: define “dropped follow‑ups, ” how inbox time is logged, and the pre/post measurement window.

Three executive actions before you pilot

Pilot scope and metrics: Start with one executive function (inbox triage, follow‑ups or task state management). Define success metrics up front (e.g., dropped follow‑ups/week, average inbox triage time, user‑reported cognitive load) and collect 30 days of baseline data.
Security checklist: Require a data‑flow diagram, encryption key ownership, retention policies, RBAC, and proof that model calls do not leak sensitive content to unaudited third parties.
Governance: Require explicit consent flows, audit logs, human confirmation thresholds for outbound actions, and a remediation plan for automation errors. Treat the assistant as an accommodation until scaled and validated.

Short, honest Q&A

Is this really accessibility and not just productivity theater?

For Johnston, yes: the assistant reduces the invisible labor of remembering, deciding and initiating that disproportionately taxes neurodivergent professionals. Framing it as accessibility centers lived need and reasonable adjustment, rather than solely squeezing output.
Are the time savings and “zero dropped follow‑ups” verified?

They are self‑reported outcomes from Johnston’s informal logs. They illustrate potential but are not independently validated; replicate measurement methods before assuming comparable gains.
Can an enterprise safely adopt this pattern?

Yes, but only with clear governance: consent, data residency, encryption controls, audit logs, RBAC, and human confirmation thresholds for actions that affect others.
Does every neurodivergent person benefit the same way?

No. This approach helps most where initiation, prioritization and working memory are the main bottlenecks. Other accommodations, sensory adjustments, meeting design, communication preferences, remain essential.
How much engineering effort is required?

Johnston built a custom MCP server and integrated connectors; expect non‑trivial developer time unless you use a managed assistant that supports editable rules and secure connectors. Budget for maintenance and security reviews.

Johnston’s best line sums the shift plainly:

“AI isn’t about making you more productive in the neurotypical sense. It’s about making the invisible labor visible and then automating it away.”, Andrew Johnston

Start small. Pick one repetitive executive function, make the start a single action, codify rules in readable form, and measure with the same method before and after. If the assistant lowers the cognitive tax on daily work, you’ve moved from a “productivity tweak” to a practical accessibility adjustment.

“Run scan”, rules do the rest.