Selected work
Intake
An internal operating system that turns fragmented requests, reports and delivery signals into reviewable, planned and accountable work.
Intake began with work I had to do almost every day
ZiniSoft develops products and delivers projects with a small team. Requests arrive through chat, email, meetings and daily reports. Before the team can begin, I often need to reread several sources, recover the context and ask more questions to understand what the real problem is.
A recorded request does not mean everyone understands the same thing. It may lack an owner, acceptance criteria or a reason it matters now. If it enters delivery in that state, the ambiguity does not disappear. It returns later as rework, a blocked decision or a result no one can confidently accept.
Before the pilot, I estimated that consolidating requests and daily reports required approximately 4.5 hours of focused CTO attention per working day. This is a personal baseline estimate, not an instrumented measurement.
AI can read quickly, but it cannot turn a proposal into a commitment
I proposed Intake and built it with the ZiniSoft team as an internal operating product, not another task manager. The goal is to preserve the journey from source input and AI proposal through human review, planning, delivery evidence and acceptance.
AI can summarize the problem, propose acceptance criteria, suggest priority and identify missing information. A plausible structure can still be wrong in context, so AI must stop before approval. The responsible person decides what needs clarification, what enters the plan and which evidence is sufficient to accept the result.
From fragmented requests to an inspectable operating loop
Before
Requests were discussed across several channels and often became delivery work only after additional manual interpretation. Progress reporting also depended on collecting updates from people and reconciling them with the delivery tracker.
Intervention
Intake was designed as an internal operating system rather than a general-purpose task manager. It connects request capture, an AI-generated proposal, human review, daily reporting, planning, delivery tracking and acceptance in one accountable journey.
AI can extract a summary, acceptance criteria, suggested priority, route and missing information. It cannot approve the request or make the final operating decision. A person remains responsible for deciding what enters planning, what needs clarification and what should stop.
Current state
Intake is in development and running as a controlled pilot across two internal product teams. The pilot covers the complete operating loop: capture, review, planning, delivery handoff, progress evidence and acceptance. Agent access is included as another controlled interface to the same work, not as an independent decision-maker.
Public evidence
- Controlled pilot across two internal product teams.
- Requests can move from source material to a structured proposal, human review and accountable planning.
- Daily reports, delivery state and acceptance evidence can be reviewed through the same operating journey.
- Human approval remains required before a proposed request becomes planned or externally tracked work.
In the seven-day measurement window reviewed on 22 October 2026, traceable in-app operating activity averaged 43 minutes per day. This measurement excludes reading time and does not represent total working time.
Approved request volume was 39 in the week of 5 October and 53 in the week of 12 October. The current partial week had reached 97 when the evidence was captured. These numbers demonstrate pilot usage volume, not completion rate or productivity improvement.
The 4.5-hour baseline and the 43-minute telemetry are not a direct before-and-after comparison because they use different measurement methods. No reduction percentage is claimed.
Public operating model
- Capture the source: a request, report or meeting outcome enters Intake with its origin preserved.
- Generate a proposal: AI structures the material and identifies missing information without making the decision.
- Review and approve: a responsible person edits the proposal, asks for clarification, rejects it or approves it for planning.
- Plan and hand off: approved work is assigned a place in the daily operating plan and connected to the delivery tracker when implementation is required.
- Return evidence: progress, blockers and delivery evidence return to the operating view so a person can accept the outcome or send it back for more work.
This is a reconstructed public model, not the internal architecture.
My role and the team’s responsibility
I work on Intake as a product builder, with responsibility for product direction, solution architecture and product operations. I define what AI may propose, which decisions require approval and what evidence must exist before work can be accepted as complete.
The ZiniSoft team builds and evolves the product. Project owners and the CTO remain responsible for approval, prioritization, planning and acceptance. AI workers structure information and suggest next steps; they do not own the final decision.
Decisions and trade-offs
One operating journey, several input channels
Chat, email, meetings, daily reports and agent tools can all create useful signals. Intake treats them as different entry points into one operating journey rather than as separate queues with separate rules.
AI proposal before human commitment
AI is useful for turning incomplete material into a reviewable proposal. The trade-off is deliberate friction at the decision boundary: work does not become a commitment simply because a model produced a plausible structure.
Internal work and delivery remain distinct
Intake keeps the request source, review history, planning context and acceptance decision. Delivery trackers keep implementation issues and engineering execution. The connection is explicit, but the responsibilities are not collapsed into one system.
A created task is not the final result
Intake retains the intake context, review history, plan and acceptance decision. Delivery tools still own technical execution. A task is complete only when the result returns with evidence that the responsible person can inspect.
What Intake changed in how I delegate to AI
Before Intake, I often evaluated an AI tool by answer quality or content generation speed. In team operations, those measures are not enough. A proposal matters only when I know where it came from, who may approve it, which action follows and what evidence will be used to inspect the result.
Intake also made another principle more concrete for me: do not automate a workflow that the team has not agreed on. AI can move ambiguity faster, but it cannot turn that ambiguity into accountable work by itself.
Publication boundary
This case describes the operating model, approved aggregate pilot metrics and reconstructed interfaces. It does not publish customer names, private source material, internal project paths, credentials, endpoints, infrastructure topology or internal architecture.
The screenshots use fictional data. The weekly counts are aggregate operating volumes. Processing-time reduction, manual-step reduction and completion-rate improvement will only be published when they share a defined workflow boundary, measurement period and source.