Why Jonny Gave His AI Agent Its Own Calendar Instead of Sharing His
Developer Jonny gave his AI agent Eddie a separate calendar instead of access to his private calendar, describing the setup in a post published on 2026-09-17 GMT Jonny's write-up.
Eddie is Jonny's personal AI agent. Jonny talks to Eddie mainly through Telegram and wants it to manage appointments for him. His private calendar remains shared only with his girlfriend. Eddie does not get access to it.
The design keeps the two stores separate. Eddie keeps its own calendar file on an external server. Jonny subscribes to that file from his own calendar app, so he can see what Eddie creates without giving Eddie a view into his personal schedule.
To build it, Jonny deployed calfeed, gave Eddie its calendar, and subscribed to the feed on his phone. Calfeed provides the hosting layer for the agent-owned calendar, with basic authentication, a simple password check, and random UUIDs, long random identifiers that make URLs hard to guess Jonny's write-up. The phone subscription only reads. Eddie writes, Jonny reads.
The broader context here is delegation under least privilege, the principle of giving a helper only the access it needs. Direct sharing would have given Eddie the same read and write scope as Jonny, including historical events, invitee lists, locations, and notes. A separate agent-owned calendar reverses that. Eddie gets full control over a narrow area, while Jonny keeps full control over the sensitive calendar and watches Eddie's through subscription.
In my view, the tradeoff is duplication in exchange for containment. Two calendars mean two sources of truth, and Jonny must decide which governs when scheduling conflicts arise. That is friction. The benefit is that the boundary stays explicit. Compromise, misinterpretation, or overeager automation inside Eddie cannot leak or change the private calendar because Eddie was never given a credential or share to it. Reversal is straightforward. Delete the subscription, rotate the credential, or retire the UUID.
Looking at what this means for operators running similar assistants, the pattern is portable because it uses only functions most calendar clients already understand. No custom OAuth scope, no per-event access list, no approval queue in between. Authentication limits access, unguessable URLs make scanning harder, and the subscription acts as a one-way mirror for supervision. The cost is that supervision stays manual. Jonny still has to check Eddie's calendar to catch errors, double bookings, or malformed entries.
Worth flagging is what this choice implies for near-term agent design. Full delegation is technically convenient and operationally brittle. Narrow, owned resources with standard interfaces are less elegant but easier to reason about, audit, and unwind. For appointments, where a single bad write can carry social cost, that caution makes sense. It lets the agent become useful before it becomes trusted.
