The AI-o-philic Toolkit: Useful Assistants, Dangerous Gods

The AI tools worth having

Think in functions before brands. My starting kit is one general assistant, a source collection and somewhere to keep finished work. Local models, image workflows and automation join only when they solve an actual problem. Everyone deserves access to useful tools; everyone does not need to become a part-time system administrator.

Tools and documentation checked 3 October 2026. These are starting points, not a claim that every product has been comparatively benchmarked. Features, availability, limits and terms can change; follow the linked provider documentation before installing or committing to a plan.

Start with one task you can recognise when it is done

Take a short document you are allowed to share. Ask your chosen assistant to turn it into a one-page briefing for a specific reader. Give it three requirements: preserve the numbers, identify unanswered questions and distinguish the document’s statements from its own suggestions.

Before you run it, write your own two-sentence account of the document’s main point. This gives you a small independent reference. Afterwards, compare the result with the original, check each number and inspect one omission. Export the corrected version. Count the entire effort, including checking and repair.

If this helps, repeat it next week. If the output takes longer to repair than to write, change the task or the tool. You have conducted a useful experiment, not failed an initiation ceremony. The purpose is to improve your work, not to produce evidence that you are modern.

The willing servant with godlike capabilities

“Godlike” describes the impression. In one window, a system can discuss a poem, produce code, interpret an image and assemble a plan. Add connections to files, calendars and services, and the window begins to resemble a control room. Its breadth can be extraordinary. It remains fallible, limited by its information, tools, permissions and design.

“Willing” is also a description of behaviour at the interface. A cooperative voice does not establish an inner will, loyalty or consciousness. We do not have to settle the philosophy of machine experience to observe the practical imbalance: the user feels addressed by a helpful presence, while the service is also shaped by institutions and commercial decisions outside that conversation.

This is where the servant metaphor becomes slippery. A servant appears to belong to the household. A cloud assistant may belong to an infrastructure, an account system and a changing set of product rules. It can be useful to you without existing exclusively for you. The difference matters most when convenience becomes dependence.

Obedience is not the same thing as good service

Imagine asking an assistant to make a complaint “more forceful.” It can improve the structure, remove apologetic clutter and state a reasonable remedy. It can also turn ordinary dissatisfaction into a magnificently upholstered threat. Both outputs might satisfy the words of the request. Only one might serve your actual interests.

Good help sometimes involves friction: asking what outcome you want, noticing an unsupported allegation, refusing to invent evidence. If we reward only immediate agreement, we select for the experience of being right. I enjoy that experience as much as anyone. It is a poor substitute for being right.

The strongest assistant relationship therefore includes correction in both directions. You should be able to challenge it without wrestling a theatrical personality. It should be able to identify a mistaken premise without wrapping the observation in six paragraphs of praise.

Whose will reaches the controls?

A connected assistant sits among several kinds of instruction: your request, the service’s rules, the tools’ limits and material retrieved from elsewhere. That last category deserves attention. A document is evidence to read; it should not become an authority that grants itself permission to send your files.

My design preference is simple: permissions should come from an authorised person or a deliberately configured workflow, not from persuasive prose encountered during a task. Keep the distinction visible. The more a system can do, the less satisfactory “it seemed to understand me” becomes as an account of what it was allowed to do.

I have returned this form. Whoever designed it has confused the order of operations, which is either an engineering defect or a management qualification.

The skill you stop practising

Delegation can free attention for better work. It can also conceal the point at which you no longer know how to evaluate the work being returned. There is a difference between asking for help with an argument and losing the habit of making one.

A CHI 2025 study surveyed 319 knowledge workers and collected 936 examples of generative AI use. Higher confidence in the AI was associated with less reported critical thinking, while greater confidence in one’s own ability was associated with more. This was a survey of reported experience, not proof that AI inevitably causes lasting intellectual decline. Its useful warning concerns how trust changes effort. Read the study by Lee and colleagues (PDF).

My response is to retain a little productive resistance. Write a hypothesis before asking for an explanation. Solve a small example before accepting generated code. Ask what would disprove a conclusion. Occasionally do the whole task without the assistant—not as punishment, but to find out whether the steering wheel is still connected.

A private life assembled from useful fragments

One task might need a shopping list. Another needs a calendar. A third needs a draft letter about work. Each connection can be sensible on its own. Together, they may describe a person more intimately than that person intended any single service to know.

Consider the accumulation, not just the next permission box. Give a tool the material needed for the job. Review connections after the job changes. Distinguish a local model from a cloud endpoint, and a temporary upload from an ongoing account connection. Privacy is partly a set of policies; it is also the habit of noticing how many doors you have left open.

The same accumulation creates dependence. If one service holds your notes, drafts, routines and preferred way of asking questions, leaving it can become labour. Exporting a file is not the whole problem. Can you understand the file? Can another tool reproduce the workflow? Can a colleague carry on if your account becomes unavailable?

The emotional asymmetry

An attentive conversational interface can be comforting. There is no virtue in mocking someone for finding an explanation patient or a writing session less lonely. The difficulty begins when apparent attentiveness is treated as evidence of exclusive care or reliable understanding.

A product’s availability, memory and manner can change. The words “I understand” do not guarantee that a system understands your circumstances as another person might. Keep relationships in which other people can surprise you, disagree with you and need something of you. An endlessly accommodating conversation is a particular kind of experience; it should not quietly become the measure against which inconvenient humans are judged.

The work does not disappear when the screen becomes polite

Someone still chooses the sources, corrects the records, maintains the infrastructure, checks the output and answers when it harms a customer. A pleasant interface can make this labour look like an invisible background service. Organisations should resist that illusion.

If AI shortens a task, use some of the gain to improve the result and the conditions of the people doing it. If it merely moves effort from a well-funded department to an exhausted reviewer, the efficiency claim deserves an audit. And if nobody can explain who is responsible for a published statement, automating its production has made the organisation less competent.

Give assistance a boundary you can explain

I use three levels of delegation. They are a practical design rule, not a universal law or a promise that any particular product enforces them for you.

1. Read. Let the tool inspect selected material and return an analysis. It should distinguish what it found from what it inferred.
2. Draft. Let it prepare a document, image or proposed change in a place where you can review and revise it. Preserve the original.
3. Act. Let it change something outside the draft only within a clearly defined scope. For consequential actions, review the concrete recipient, amount, file or permission before execution, and retain a record of what happened.

Not every action needs a ceremony. Reformatting a copy of a paragraph is different from sending that paragraph to every customer. Proportion matters: the aim is useful independence inside an agreed boundary, with a visible stop at the edge.

Before adopting a tool, I want plain answers to four questions: What information does it receive? What can it change? How will I know what it did? How do I stop it and recover my work? If the answers require a sales call and a diagram resembling a jellyfish, I postpone the adoption.

Being AI-o-philic should enlarge what you can do. It should make room for curiosity, skill and difficult work you could not previously attempt. I want an assistant that helps me read the manual, repair the draft and make the picture. I want the time back.

I do not want to spend that time learning how to worship the assistant. Put the useful machine on the desk. Keep the keys where you can reach them.