The useful part was not the provider count
Zakera began as a broad AI orchestration prototype: a FastAPI backend, a Next.js interface, provider adapters, conversation memory, tools, authentication, and monitoring. That breadth proved the pieces could be connected, but it also hid the harder product question.
If an agent can call a tool on someone’s behalf, what can that person see, stop, approve, and understand?
An agent run should be inspectable work, not a longer loading state.
Turning chat into a run
The most useful part of the current prototype is its run model. A request creates an agent run. Work inside that run is recorded as ordered steps. Each step can carry a label, status, tool name, detail, token count, latency, error, and metadata.
The interface exposes those records in an Agent Runs drawer rather than collapsing everything into one assistant message. A person can select a run, follow its steps, and see whether it completed, failed, was rejected, or is waiting for approval.
That is still a small implementation, not a complete workflow engine. Its value is that it establishes the object the redesign can build around: a reviewable record of work.
Approval is a boundary, not a badge
The current service pauses selected tool calls, including code execution and file reading, and creates an approval record before continuing. The interface presents approve and reject actions for pending requests.
This is evidence of the approval path, but not evidence that every consequential action is safely classified. A two-item risk list is only a starting point. The redesign needs an explicit action policy that distinguishes reading, drafting, changing local state, and acting on an external system.
What exists now: persisted runs, ordered steps, event details, pending approvals, and approve or reject controls in the interface.
What remains: a complete action policy, isolated project workspaces, durable background execution, reviewable long-term memory, and a verified owner setup path.
Why the redesign is narrower
The earlier repository describes a general assistant with many providers, persistent memory, tools, failover, and production monitoring. Some of those modules exist in code, but their presence does not prove a reliable end-to-end product.
The redesign therefore starts with a smaller promise: an owner runs Zakera for their own projects, gives it only the context and tools that project permits, and can inspect the work before accepting consequential changes.
That framing makes the product easier to evaluate. The question is no longer “how many providers does it support?” It is “can one owner complete one real project workflow and understand every important action along the way?”
Current state
Zakera is pre-alpha. The run trace and approval concepts are implemented in the existing prototype. Reviewable long-term memory, durable background work, isolated project execution, and a fully verified installation are not complete.
The case study is intentionally about that boundary. The project has enough working material to reveal the right architecture, but not enough evidence to claim a dependable personal agent platform yet.
