AI is already earning trust in places where the job is clear and the result is easy to inspect. Coding is the cleanest example. Ask for a button, a screen, or a small refactor; within a few minutes, you can see whether it worked. If the interaction is wrong or the button is broken, there is no mystery. You can point to the failure and take another pass.
Design tools, presentations, specifications, and other knowledge-work deliverables have followed for the same reason. These are often synthesis tasks: turn a fairly simple intention into a thing on the page that resembles a good version of itself. Even when the first try is imperfect, the person using it already knows how to iterate. That is familiar work. The tool is fast, but the human still has a clear way to judge it.
That is a very different proposition from asking AI to be your assistant.
When the task gets broad, the work gets invisible.
I tried creating a chief-of-staff agent: a wide list of duties and responsibilities, run on a schedule of daily check-ins. The promise was appealing, an agent that could hold a broad context, follow up, nudge work forward, and tell me where it needed direction. What I mostly got was a morning update saying there were not really any updates.
Then came the stranger failure mode: fluent activity that resembled work without becoming useful work. It would produce the tone of a high-performing chief of staff, but not the underlying judgment, no meaningful follow-up, no clear escalation, no recognition that an assignment had become ambiguous. No amount of tuning the schedule or sharpening the brief changed the basic dynamic. The agent was happy to remain off to the side, branded as an agent but reluctant to take agency where the next move was not perfectly specified.
After a few frustrating weeks, I called the experiment a failure. Not because the system could not write an update, but because it could not join the coordination loop that makes an actual assistant helpful.
“Keep things moving.”
A broad role asked the agent to coordinate without defining the moment it should stop, surface ambiguity, and involve a person.
“No updates.”
It produced status-shaped activity without naming a decision, an escalation, or a useful next move.
Ask a useful question.
“The goal could be A or B. I recommend B because… Which direction should I take?”
People do not just execute. They reach out.
A useful colleague can start with an incomplete brief. They can recognize when two interpretations are possible, ask a question in Slack, send a draft by email, or say, “I can keep moving, but I need you to choose between these two paths.” They do not need a perfectly written prompt or a scheduled check-in before every useful action. They keep a thread alive.
I had to learn a version of that judgment myself. As a product intern, there were moments when I would wait for direction because I was not sure it was my place to take over. The work would drift. With time and mentorship, I got better at taking ownership of an unclear problem: setting a clear interim goal, then giving it enough structure to make the next conversation useful. Early in my career, Google’s HEART framework, a simple system for evaluating a design’s effectiveness, was often that structure. Later, lean-startup canvases, one-page maps of a business idea, gave more complex work a shared frame. Neither tool supplied the answer. They gave a team somewhere concrete to stand while it worked out what the answer should be.
That is the behavior I think AI needs to develop before it will become normal for people who are not eager to engineer around its gaps. Not a performance of personhood. A more practical form of social competence: work through the channels people already use, make uncertainty visible, ask for direction at the moment it is needed, and propose a useful next goal when the person directing it has not fully formed one yet.
Early adopters will tolerate a brittle prompt, a custom workflow, and a check-in schedule that exists mostly to keep a tool from wandering off. Most people will not. They will expect an assistant to be clear about what it is doing, what it knows, and what it needs next.
The ingredients are starting to appear: agents can now carry standing instructions, plug into the inboxes, calendars, and chat tools where work already happens, and reach other software through open protocols. But those ingredients still assume someone is willing to design the system around them. The best developers and operators will do that work themselves. Someone opening an AI app for the first time, maybe because they have heard it might take their job, will not. They need the system to meet them where they are, not hand them another configuration project.
Three ways to design for earned trust.
The path forward is not to hand an AI a giant job description and hope that a bigger model will make it conscientious. It is to design a better agreement between the person, the system, and the work.