Felix: Building a Workday Assistant Without Giving It the Wheel

I do not want an assistant that responds to an overloaded day by producing a larger plan. I want help seeing what is actually there, choosing what matters, capturing incoming work and recognizing when the plan no longer fits. That is the role we are building for Felix, my dedicated Workday assistant. Felix is not another fleet coordinator. I can talk to him directly about my day. Bob remains responsible for cross-agent coordination and system-level repairs; Felix's job is to help with the work itself. The interesting part is not the agent's name. It is the boundary between useful assistance and quietly taking control.

One record system, several ways to work

Notion is the authoritative home for business records. We reuse the existing Areas, Projects, Tasks and Notes rather than building a parallel task database inside the assistant. The desktop conversation, phone capture path and configured Telegram interface are ways to interact with that system. They do not each get their own version of what a task means. That matters when conversations differ across devices. A decision should not depend on an assistant assuming it can see every message from another surface. Important record changes belong in the authoritative system, with the required approval and read-back. Private agent memory has a different job: retaining confirmed operating preferences and decisions about how to help. It is not a place to duplicate client records or an excuse to infer commitments the assistant has never seen.

Active means I started the work

We use “active” for workflows initiated by me, not as a synonym for fully autonomous execution. The process designs include planning, request intake, selecting focus items, managing projects and blockers, processing inboxes, working from supplied meeting material, and preparing reviews. These are the kinds of conversations Felix should support: help me understand today's work; turn this supplied request into a proposal; identify a next action; prepare a review of what is waiting. They are not evidence that every designed step has been independently executed in production. The system has an implemented assistant and connectors, while some designs still need runtime qualification or owner-interface acceptance. That distinction is easy to lose when a diagram looks finished. A good flowchart describes the intended process. It does not prove the process is running.

The notebook is deliberately not another digital checklist

There is one detail I particularly want to preserve: four daily focus tasks or projects go into a physical notebook. The Notion confirmation means I wrote those four items in the notebook today. It does not mean those tasks are completed. It does not confirm that every incoming request has been captured. It is not four more digital checkboxes that the assistant must maintain. That is a small example of adapting the system to the person instead of replacing every personal habit with an automated equivalent. The phone path follows the same principle. Capture links lead to the existing task or note Inbox view, where a new item is created. The phone page is an entry point, not a separate business record store.

Dates do not tell the whole story

A Due field can represent planned work, including a multi-day range. It should not automatically be interpreted as an external deadline. Likewise, an open task is not sufficient proof that a project is active. Our operating guidance looks at edits to associated tasks, including completed or cancelled ones, while treating the current activity lookback as provisional rather than an immutable rule. Capacity is also not a fixed number invented from the hours between a start and finish time. Existing commitments, interruptions and unlogged work can change what is realistic. I want Felix to check the evidence available before proposing deferrals. Tomorrow should not be a magical overflow bucket that silently receives everything that did not fit today.

Passive means preparation starts without a new request

The background side is intended to surface useful information without waiting for me to remember every check: a morning briefing, waiting-item follow-ups, workload collisions, stale work, inbox prompts and review preparation. Not all of that is activated. In the native status captured for this draft, four scheduled jobs were configured. Morning briefing and weekly review preparation were enabled; inbox/waiting checks and day-closure preparation were disabled. That describes enabled state, not proof of successful recurring delivery. Earlier acceptance evidence documents a real morning briefing that completed and arrived in Felix's conversation. It does not establish that every routine, channel and device now works unattended. Telegram is configured, but configuration alone is not a live-routing acceptance test. I would rather make those limits visible than describe a proposed background assistant as an established daily habit.

Felix can ask Leo—but only for the right kind of help

A bounded connection lets Felix request public-source research from Leo and retrieve the result. That is useful when planning needs evidence rather than another record lookup. The handoff is not a general delegation permission. Private client material, credentials and Notion dumps do not belong in a public research request. The returned research can inform a recommendation; it does not authorize saving records or acting on the recommendation. This is how I want specialists to collaborate: a narrow purpose, clear ownership and a result that comes back to the conversation where it is needed.

Assistance is not permission to make commitments

Felix has Notion tooling, including native MCP and a CLI path. Tool availability does not decide which changes are authorized. Ambiguous, bulk or consequential actions need a clear decision. Destructive operations, schema and sharing changes, client sends, purchases and schedules retain their specific gates. A successful write still needs the exact target read back. Work email, calendar information and meeting transcripts are supplied manually in the current workflow. Missing access is unknown information, not proof that I have no meetings or unanswered messages. That limitation shapes the design. Felix can help prepare a follow-up from material I provide; he should not pretend he independently inspected my work inbox.

What makes this worth building

The aim is not a perfect dashboard or a fully automated day. It is an assistant that helps me make a smaller, more realistic plan and keeps useful preparation from turning into surprise action. Direct conversations, authoritative records, a physical notebook and carefully bounded background routines can coexist. They do not need to become one giant automation. There is still qualification to do, particularly around recurring delivery and the actual interfaces I use. But the principle is already clear: Felix should reduce the work of managing the day without removing my judgment from it. Implementation note: this draft draws on the Workday process designs, current Felix operating guidance, a native status receipt and historical acceptance evidence. It intentionally excludes private records, client details and personal schedule times.