Why Approval Comes Before Automation

The most convenient moment in an automated system can also be the moment when the user loses control. A draft becomes a sent message, a recommendation becomes a booked appointment or a prepared application becomes a public submission. The system may have saved a click, but it has also crossed from helping the person think into acting in the person’s name. That change is small at the level of the interface and significant at the level of responsibility.

As AI becomes more capable, the pressure to cross that boundary will increase. An assistant that can write, schedule, search, organise and make recommendations will appear more useful if it can also send, book, apply, move and decide. Some actions genuinely benefit from automation, especially when they are routine, reversible and well understood. The difficulty is that capability does not tell the system which actions the user is ready to delegate. Being able to act is different from having permission to act.

This is why approval is a central principle behind Fred+Teff. The aim is not to build an assistant that takes over as much work as possible. It is to build one that can understand a task, prepare the work and reduce the effort required to complete it while leaving final authority where the consequences belong. The user should not have to supervise every minor step, but the system should not treat the absence of resistance as consent.

Consider a request to help with five AI evaluation job applications. A useful system could identify suitable roles, compare them with the user’s experience, organise deadlines, adapt a CV and prepare cover letters. Each of those steps reduces work without creating an external commitment. Submission changes the nature of the task. The application represents the person, shares information with another organisation and may contain details the user wants to review. Approval at that point is not evidence that the automation failed. It is recognition that preparation and representation carry different levels of consequence.

The same distinction applies elsewhere. An assistant can draft an email without being authorised to send it. It can propose a calendar change without deciding that another person’s time should be moved. It can organise financial information without transferring money, and it can prepare a workflow without exposing private files to a new service. In each case, the system remains useful before it acts. Approval creates a place where the user can inspect what the system understood, what it intends to do and which information will leave the private workspace.

That inspection matters because an AI can be coherent and still misunderstand the request. Context may be incomplete, an old preference may no longer apply or a reasonable instruction may carry a consequence the system cannot see. Once an action reaches the outside world, correcting the misunderstanding may become harder. A message can be read, an application can enter a hiring process and a payment can affect another account. Approval interrupts the chain while the cost of correction is still low.

Products often treat friction as a design failure, and much of the time they are right. Repeating unnecessary confirmations makes a system tiring to use and can train people to approve without reading. Trust design is not about placing the same warning in front of every action. It requires the system to distinguish between low-risk assistance and consequential execution, between actions that are reversible and those that are not, and between a preference already delegated by the user and a new decision that still needs attention.

That means approval should be proportionate. A user may choose to let the system rename files according to a known rule while requiring confirmation before any file is deleted or shared. Calendar suggestions may be prepared automatically, while invitations remain subject to review. Over time, the person may deliberately expand or reduce what has been delegated. The important point is that the boundary is visible, understandable and controlled by the user rather than inferred permanently from one previous choice.

Approval then becomes part of the intelligence rather than a restriction placed around it. A trustworthy system needs to know not only how to complete a task, but when its understanding is sufficient, when uncertainty matters and when another person must make the final judgement. Stopping can be the more intelligent action when the system has reached the edge of its authority. Asking is not weakness when the alternative is confident action based on an assumption.

The future of personal AI will be shaped by the balance between assistance and agency. Too little automation leaves the user carrying work the system could safely reduce. Too much uncontrolled automation creates a system that is efficient until the first serious misunderstanding, after which every convenience is judged against the loss of trust. Approval protects the relationship by allowing capability to grow without making authority disappear. Automation becomes genuinely useful when the system can do more, but still understands that the actions which matter belong to the person whose life they affect.