Inspiration
Life admin sounds simple until everything starts piling up.
A tenancy agreement contains one deadline. A university document contains another. An employment letter has dates and conditions that matter. Bills need attention, appointments need remembering, and important information can be buried halfway through a document you read once and then forget about.
What interested me was that the problem usually isn't just understanding these documents. The harder problem is working out:
- What actually matters?
- Do I need to do anything?
- How serious is it?
- What can wait?
- Is something unclear or contradictory?
- What should I do next?
There are already plenty of tools that can summarise a PDF or answer questions about one. I wanted to build something that went a step further.
That became LifeOS: an autonomous personal administration agent that turns scattered documents into clear priorities and safe, actionable next steps.
The goal wasn't to build an AI that takes control of someone's life. It was to build one that helps them stay in control of it.
What it does
A user uploads an administrative document and LifeOS works through it as part of a larger personal-admin workflow.
Instead of stopping at a summary, it:
- Understands the document and its purpose.
- Extracts important facts, responsibilities, deadlines and conditions.
- Keeps source evidence attached to the information it extracts.
- Identifies missing, ambiguous or contradictory information.
- Determines whether each item needs attention now, later, repeatedly, conditionally, or not at all.
- Assesses priority based on potential consequences.
- Decides what the safest useful next response should be.
- Creates an action plan.
- Requests approval where appropriate.
- Uses a supported tool to prepare a draft, reminder or checklist.
- Verifies the result after execution.
- Stores the state in a persistent cross-document Action Centre.
The Action Centre brings information from different documents together under:
- Needs Attention
- Upcoming
- Recurring
- Reference / Conditional
- Completed
This was important to me because real life admin doesn't happen one PDF at a time.
From understanding to action
One of the main ideas behind LifeOS is separating what something is from what should be done about it.
An item might be a deadline, payment, appointment, renewal, communication requirement or simply useful information.
But that alone doesn't determine the right response.
LifeOS separately reasons about whether the most useful response is:
- a draft
- a reminder
- a checklist
- a review
- or no action
For example, a document does not need to explicitly say "email someone" for LifeOS to recognise that a material discrepancy may be best resolved through written clarification.
At the same time, I didn't want it generating actions just for the sake of looking agentic. Purely informational items can remain informational, and internal tasks shouldn't become unnecessary emails.
Understanding priority
Another thing I wanted LifeOS to understand was that important and urgent are not the same thing.
A low-impact task might be due tomorrow, while another issue could have major financial, contractual or administrative consequences despite having more time available.
LifeOS considers signals such as deadline proximity, financial impact, potential loss of rights or benefits, irreversible consequences, blocked important tasks and unresolved discrepancies.
Items are assigned a priority from low to critical, alongside a short "Why this matters" explanation.
That priority then affects how information is surfaced in the Action Centre.
Evidence-first reasoning
Administrative AI becomes risky very quickly if it confidently fills in information that isn't actually there.
I therefore designed LifeOS around an evidence-first principle.
The system distinguishes between information supported directly by a document, information derived from it, uncertainty, and recommendations.
If a date looks suspicious, LifeOS doesn't silently replace it with the date it thinks the author probably intended.
During testing, for example, I used an employment letter whose document date and promotion effective date had a major chronological discrepancy. LifeOS preserved the dates from the source, recognised that the discrepancy could affect employment and payroll records, and recommended requesting clarification instead of silently correcting it.
Uncertainty can also affect execution. If information required for an action is materially uncertain, LifeOS can block that action rather than continuing with an assumption.
How I built it
LifeOS uses Gemini 3.5 Flash through Vertex AI, with the Google Agent Development Kit (ADK) for the agent layer.
The backend is built with Python, FastAPI and Pydantic.
The application is containerised and deployed on Google Cloud Run, while Cloud Firestore provides persistent state for analyses, administrative items, plans, drafts, reminders, checklists and action history.
The frontend is built with HTML, CSS and JavaScript.
At a high level, the architecture is:
Document → Ingestion → Quality Check → Gemini/ADK Understanding → Admin Items → Priority & Response Strategy → Deterministic Planner → Approval → Tool → Verification → Firestore → Action Centre
One design decision became especially important: Gemini does not directly control execution.
Gemini handles the parts that benefit from semantic reasoning, including:
- document understanding
- uncertainty detection
- administrative item extraction
- priority reasoning
- response strategy
- evidence-grounded draft generation
Deterministic application code controls:
- stable identity
- planning
- permissions
- approval
- execution state
- tool execution
- persistence
- verification
This gave me a much clearer boundary between an AI recommending an action and the application actually performing one.
Safe actions and verification
LifeOS currently supports three application-managed action tools:
Drafts
LifeOS can prepare communications for clarification, missing information, disputes, confirmation requests and similar situations.
Drafting is deliberately separated from sending. LifeOS does not automatically send communications.
Recipient handling is evidence-aware as well. If a trustworthy recipient cannot be established from the source, LifeOS uses a placeholder instead of inventing one.
Reminders
LifeOS can create persistent reminders for deadlines, appointments, renewals, payments and recurring responsibilities.
A payment reminder, for example, does not give the system permission to make the payment.
Checklists
LifeOS can generate persistent checklists for administrative tasks involving multiple steps.
After executing one of these supported actions, LifeOS performs read-back verification.
I wanted the system to distinguish between:
"The agent tried to do this."
and
"The application verified that this action actually exists in the expected state."
Actions therefore move through an explicit state machine from planning and approval through execution and verification.
Failed attempts are also preserved rather than hidden. A failed action can be retried through a fresh plan while keeping the previous attempt as history.
The biggest technical challenge: documents that "successfully" fail
One of my favourite problems during development came from a two-page employment letter.
Visually, the PDF contained a complete document.
My PDF parser reported that extraction had succeeded.
The meaningful text it returned was essentially:
01 02
Nothing crashed. No exception was thrown. Technically, the parser had done its job.
But LifeOS had almost no usable information to reason from.
That exposed a bigger problem: successful extraction is not necessarily good extraction.
I redesigned the ingestion pipeline so PDF extraction passes through a quality gate. The application looks for signals such as meaningful text volume, alphabetic content and word count rather than trusting a parser simply because it returned something.
If extraction quality is poor or the document is primarily visual, LifeOS falls back to Gemini's multimodal understanding.
That experience reinforced one of the biggest lessons from this project:
Better reasoning cannot compensate for bad input.
Another challenge: tests passed, reality didn't
I also learned not to rely entirely on mocked model behaviour.
At one stage, the automated tests around draft generation were passing, but a real Gemini/Vertex call still failed because of how recipient placeholders were being validated.
Fixing that led me to move recipient selection out of creative model generation and make it deterministic.
The application now builds trusted recipient candidates from evidence. If there isn't a clearly appropriate recipient, it uses a safe placeholder rather than asking the model to invent or infer one.
That bug taught me that testing an AI application means testing more than individual functions. The contract between model output and deterministic application code matters just as much.
What I learned
This project taught me far more than how to call an AI model.
I learned how important it is to design around uncertainty rather than treating it as an inconvenient edge case.
I learned that the model should not necessarily control everything just because it is capable of reasoning about everything.
I learned why stable state, approval guards, tool boundaries and verification matter when moving from an AI that produces text to an agent that can take actions.
I learned that ingestion quality has to be tested independently from reasoning quality.
And I learned the importance of testing against the real model rather than assuming mocked outputs capture every integration failure.
Probably the biggest change in my thinking happened when I stopped asking:
"What should LifeOS do with a tenancy agreement?"
and started asking:
"How should LifeOS reason about an administrative responsibility, regardless of which document it came from?"
That shift helped me move away from document-specific rules and towards a more general personal administration agent.
Challenges I faced
Some of the main challenges included:
- extracting useful information from inconsistent and visually structured documents
- preventing hallucinated administrative details
- preserving evidence and uncertainty throughout the workflow
- deciding when an issue genuinely deserves action
- distinguishing importance from urgency
- deciding when written communication is the safest next step
- preventing the model from inventing recipients
- separating AI reasoning from deterministic execution
- implementing approval and action-state transitions
- verifying tool execution instead of assuming success
- maintaining state across documents and server restarts
- recovering cleanly from failed actions
- keeping cached analyses compatible as the reasoning system improved
- deploying the application and its AI/cloud dependencies to Cloud Run
Several of the most useful improvements came directly from failures rather than from the original design.
Accomplishments I'm proud of
I'm particularly proud that LifeOS became more than the document summariser I originally wanted to avoid building.
The final prototype can take unrelated administrative documents, reason about their importance, identify uncertainty, choose different response strategies, safely execute supported tools, verify the result and remember state across documents.
I'm also proud of the safety boundary between generative reasoning and deterministic execution.
LifeOS currently has 94 automated tests, alongside manual testing against real Gemini/Vertex calls and unrelated document types.
The application is deployed publicly on Google Cloud Run with persistent Firestore-backed state.
Most importantly, the architecture is general enough that adding a new administrative document should not require adding a new set of rules specifically for that document.
What's next
There are deliberately several things LifeOS does not automate yet.
Future versions could extend the existing tool architecture with:
- Gmail draft integration
- Google Calendar
- notifications
- deadline and document-expiry monitoring
- recurring personal-admin reviews
- secure multi-user authentication
- encrypted document storage
- more document formats
- user-defined automation policies
I would also like to explore how LifeOS could safely become more proactive over time — not just responding when a document is uploaded, but noticing when an unresolved obligation is approaching and deciding when it is actually worth interrupting the user.
For now, consequential external actions remain intentionally limited.
I'd rather have LifeOS tell the truth about what it did, ask when it doesn't know enough, and keep the user in control than make the prototype look more autonomous by giving it authority it shouldn't have.
The longer-term goal is simple:
Turn scattered life admin into something understandable, actionable and much harder to forget.
Built With
- artifact-registry
- cloud-build
- cloud-run
- css
- docker
- fastapi
- firestore
- gemini
- google-adk
- google-cloud
- html
- javascript
- pydantic
- pypdf
- python
- python-docx
- uvicorn
- vertex-ai
Log in or sign up for Devpost to join the conversation.