AI helps me build faster, but it does not get to decide

Why I built Intake

In a small team of about ten people working across several projects, requests do not arrive through one channel. Work can begin in a message, an email, a screenshot or one sentence during a meeting. Before delegating it, I still need to read the source, recover the context, identify the project, set priority and decide whether the request is clear enough to act on.

As CTO, I sometimes become the person standing between almost every input and the work that follows. The problem is not that the team lacks a task tool. Context gets lost when a conversation becomes an assignment, and responsibility is not always recorded clearly.

We built Intake from that situation. ZiniSoft has used it in a controlled internal pilot since early October 2026. In this talk, I used the system itself to examine one question: can AI help a team move faster without taking the right to decide?

What I used to get wrong

I once thought that the difficult part was over when a request had become a tidy task. A concise title does not guarantee that it preserves the sender’s intent. The person doing the work may also have no shared evidence for what “done” means.

In one case, an end-of-day report said that an item was complete, but the Issue remained open in the source management system. No one was trying to be misleading. We were using two different definitions of complete.

That changed how I review work. A completion statement is not enough for acceptance. The result needs a trace that the responsible person can inspect, such as an updated Issue, a recorded change or a documented reason for an exception.

Five steps from request to evidence

1. Capture: retain the request and its original source, not only the version already interpreted as a task.
2. Structure: AI reads, classifies and proposes a clearer version. It is still a draft.
3. Approve: the person who understands the work edits the content, sets priority and owns the approved version.
4. Act: the system creates an Issue or adds work to the plan only from approved content.
5. Audit: state, decisions and evidence remain available for another person to inspect.

These steps do not depend on one AI model or task management tool. The boundary I want to preserve is simple: AI can prepare a decision, but it cannot turn its own proposal into a real action.

What I demonstrated live

During the demo, feedback entered Intake through its actual intake path. AI read it and proposed a structured request. I reviewed the proposal, changed the priority and approved it before the system created an Issue. The Issue then appeared in the work plan for the responsible person to arrange.

The important point was not task creation speed. A task created quickly with the wrong context only helps the team move in the wrong direction faster.

The most useful moment came during acceptance. I tried to confirm work that did not have evidence. The system did not treat it as a normal completion and asked me to provide a reason. I stopped.

It blocked the CTO. That is intentional. The title of the person pressing the button should not replace evidence that the team agreed on beforehand.

Another part of the talk showed an agent stopping when the project profile was incomplete. It did not create a branch, read the Issue or change code. When context is missing, the most responsible AI response can be to take no action.

What I learned from using it with the team

After using Intake with my own team, I no longer treat task creation as the result. The result matters only when I can answer three questions:

1. Where did this request come from, and what was the original input?
2. Who read, changed and authorized the action?
3. What evidence shows that the work is actually complete?

AI reduces the time I spend reading, structuring and cross-checking information. Priority, delegation, exceptions and acceptance still need a named person who is accountable.

This is also the connection between two Operator Notes: writing down a request does not create shared understanding and clarifying the workflow before adding more AI agents.

Start with one small workflow

You do not need to build a system like Intake. Choose one job in which AI already helps your team and write down three boundaries:

• What may AI read, structure or propose?
• Who approves before that proposal becomes an action?
• What evidence must the reviewer see before trusting the result?

If the second and third questions do not have answers, the next step is not another agent.

Scope of the demo

This is a controlled internal pilot, not a case proving ROI or autonomous operation at scale. The demo shows that a workflow can retain source context, enforce an approval gate and require evidence before acceptance. It does not show that the model fits every team.

The illustrations on this page were reconstructed for public use. I do not publish the internal deck, backup video, customer data or internal architecture.