Inspiration
Important responsibilities often arrive disguised as ordinary email sentences: “I’ll send the report next Thursday,” “Can you review this document?”, or “Let’s reconnect after the experiment.” Traditional email tools organize messages, and AI assistants generate replies, but neither reliably tracks whether the underlying promise was actually completed.
We built Lucy: The Email Secretary to manage those unfinished commitments. Lucy does not optimize for sending more email. It identifies what people expect next, tracks the evidence across email, attachments, documents, and calendars, and continues working until the expected outcome is completed, intentionally postponed, transferred, or cancelled. This directly reflects the hackathon’s focus on agents that plan, act, observe, and self-correct instead of stopping after a single model response.
What it does
Lucy converts real email conversations into persistent, outcome-driven loops.
For example, during a conversation with a professor, the user promises to submit a Phase 1 research report by next Thursday. Lucy extracts:
- The promise: submit the Phase 1 report
- The owner: the user
- The deadline: the correct calendar date derived from the email timestamp
- The intermediate steps: preliminary research, report preparation, and review
- The expected outcome: the correct report is delivered in the original email thread
Lucy then continuously runs the following loop:
Observe → understand → plan → act with permission → verify → repair → repeat
It may recommend reserving research time, locate the relevant attachment, prepare a reply, or simply wait when intervention is unnecessary. After an approved action, Lucy checks the real result. A successful API response is not enough. Lucy verifies the recipient, thread, message, attachment, and expected outcome before closing the commitment.
Lucy uses several specialized agents:
- A Commitment Extractor identifies promises, requests, deadlines, owners, and expected outcomes.
- A Planner chooses the smallest useful next action.
- A Critic challenges unsupported assumptions and unnecessary interventions.
- An Action Agent prepares approved drafts and calendar actions.
- A Verifier checks whether the real-world outcome occurred.
- A Preference Agent learns from corrections, approvals, rejected drafts, and reminder behavior without autonomously changing high-risk policies.
All external actions remain approval-gated. Lucy can prepare work autonomously, but it cannot quietly send an email or modify the calendar.
How we built it
Lucy is built as a backend-first Python system on top of the existing CPOS architecture. It uses FastAPI, PostgreSQL, Redis, structured agent outputs, persistent loop states, an evidence ledger, and an append-only audit trail.
Incoming Gmail messages, conversation metadata, and attachments are processed through Nexla. Nexla provides the Gmail data pipeline and transforms fragmented email data into normalized, governed records that Lucy’s agents can consume consistently. Nexla’s Gmail integration supports messages, drafts, labels, and attachments, while its MCP approach allows task-specific tools to expose only the context required for a workflow.
We designed an incremental thread-processing pipeline to reduce unnecessary LLM calls. Lucy parses MIME content, HTML, quoted history, signatures, documents, and attachments deterministically first. When a new message arrives, the model analyzes only the new semantic information and merges it into the existing thread state instead of repeatedly summarizing the entire conversation.
The Python services, workers, language models, PostgreSQL database, Redis, and object storage are hosted using Akash. GPU-backed model inference supports structured extraction, planning, criticism, and verification. Because Akash container storage is ephemeral by default, the database and attachment services use persistent volumes for durable state.
Pomerium protects Lucy’s APIs, agents, and MCP tools. Each agent receives its own identity and limited permissions. The extraction agent can read the active thread but cannot send mail. The planner can propose an action but cannot execute it. The action service can perform a sensitive operation only when the user’s approval matches the exact recipient, body, thread, and attachments. Pomerium sits between agents and protected resources to enforce authentication, authorization, and observability for each request.
Zero.xyz is used only when Lucy needs an approved external capability that is not part of its core email system, such as validating a public link or retrieving public context referenced by a message. Zero allows agents to discover and invoke real external tools, while Lucy adds read-only policies, cost limits, and sensitive-data restrictions around those calls.
Personal communication, approvals, extracted commitments, and audit history remain encrypted and under the user’s control. We used real Gmail conversations, real attachments, real provider responses, and real loop transitions rather than mock inbox data or hardcoded successful outcomes.
Challenges we ran into
The first major challenge was that an email thread is not a clean sequence of independent messages. Replies contain quoted history, repeated signatures, forwarded content, inline images, malformed HTML, and attachments in many formats. Sending every complete thread to an LLM was both expensive and unreliable, so we built deterministic parsing and incremental state updates.
The second challenge was understanding commitment language. “I will submit it Thursday” is a firm promise, while “I should be able to look next week” is tentative. Lucy needed to preserve that uncertainty instead of inventing a deadline or treating every polite sentence as a task.
The hardest challenge was verification. Creating a draft is easy; proving that a human obligation was fulfilled is not. Lucy must distinguish between a tool call succeeding and the promised outcome occurring. A message sent to the wrong thread, without the expected attachment, should not close the loop.
Security was another major challenge. Email and attachments are untrusted inputs and may contain instructions that attempt to manipulate the agents. We therefore separated reasoning from execution, restricted every agent’s access, required exact approval binding for external writes, and treated message content as data rather than authority.
Accomplishments that we're proud of
We are proud that Lucy is not another email-writing wrapper. The central abstraction is a durable outcome loop with an owner, deadline, desired state, evidence, action history, verification method, and stopping condition.
We built the system around restraint as well as action. Lucy can decide that the correct next step is to wait, request clarification, or avoid sending a follow-up. That makes it useful for real professional communication rather than turning it into a spam engine.
We also created a verification-first action model. An approved email action is cryptographically tied to its recipient, thread, subject, body, and attachments. If any part changes after approval, the authorization becomes invalid. The loop closes only after Lucy observes supporting evidence from the real system.
Finally, we connected the sponsor technologies around clear responsibilities rather than adding integrations for decoration: Nexla supplies governed communication data, Akash runs the backend and model infrastructure, Pomerium protects agents and sensitive tools, and Zero provides bounded external capabilities.
What we learned
We learned that the most difficult part of an email agent is not generating polished text. It is maintaining an accurate model of what is currently true, what somebody expects, what evidence is missing, and when the agent should stop.
We also learned that a good agent loop needs explicit state. Without a desired outcome, post-action observation, verifier, repair policy, and stopping condition, an “agent” is usually just a chain of prompts.
Incremental context was another important lesson. Most of an email thread does not change when one new reply arrives. Parsing and caching unchanged information locally, then sending only the meaningful delta to the model, reduced duplicated reasoning and made the system easier to audit.
Most importantly, we learned that autonomy must be earned. Agents should independently perform reversible analysis and preparation, while sensitive external actions remain narrow, inspectable, and approved by the user.
What's next for Lucy : The Email Secretary
Next, we want Lucy to support a broader set of communication loops across Gmail, calendars, local documents, research workflows, and team communication systems while preserving the same local-first and approval-gated design.
We plan to improve commitment extraction for conditional promises, multi-person ownership, changing deadlines, and long-running projects. We also want to add stronger progress signals so Lucy can understand when work has begun without reading unrelated personal files.
Lucy’s preference-learning system will evolve through explicit, reversible user-approved rules rather than hidden behavioral profiling. It will learn practical patterns such as preferred reminder timing, communication style, and when the user usually wants a calendar block.
Longer term, Lucy can become a personal operating layer for human commitments: not a system that sends more messages, but one that helps people keep the promises already inside them.
Log in or sign up for Devpost to join the conversation.