Triage-Life

Triage-Life is an AI agent that turns overwhelming life admin into clear decisions.

Comment

Inspiration

Life admin is one of those problems that is easy to underestimate. An insurance renewal, a school form, or an appointment letter may look like a single task, but each one requires a person to read carefully, identify what matters, understand what is being requested, track a deadline, decide what to do, and often draft a response.

The individual tasks are small. Together, they create a constant background load of unfinished decisions.

We were inspired by the idea that personal AI should not become another inbox, chat window, or dashboard that people have to manage. It should work quietly in the background and appear only when a human decision is genuinely required.

That led to the central product principle behind Triage:

Triage never asks the user to read the paperwork again. It asks only for the decision the paperwork requires.

What Triage does

Triage is an AI agent that turns life-admin documents into a prioritized decision queue.

A user can upload documents such as insurance notices, school forms, and appointment letters. Triage stores the original document, extracts its text page by page, identifies obligations and deadlines, detects amounts and missing information, and creates a clear next step for the user.

For actionable documents, Triage prepares a draft response. The user can review the extracted facts, inspect source quotes and page references, edit the draft, and approve or reject the proposed action.

Triage does not send messages or make consequential changes autonomously. Every action stops at a first-class approval gate. The exact approved payload is recorded, and any edit after approval invalidates the approval and requires the user to approve again.

Version one uses simulated execution for safety. The approval record is intentionally designed as the integration boundary for future email, calendar, and form-submission connectors.

Triage prioritizes work using a transparent combination of urgency, impact, and confidence rather than allowing the model to assign an unexplained score. Conceptually, the priority of an obligation can be represented as:

P=wuU+wiI+wc(1−C)P = w_u U + w_i I + w_c (1 - C)

where U represents deadline urgency, I represents potential impact, C represents extraction confidence, and wu, wi, and wc are configurable weights. In the implementation, this logic is validated and normalized by application code before an item enters the decision queue.

How we built it

Triage is a full-stack web application with a React frontend and a typed server API. The interface is designed as a calm personal operations desk rather than a generic chatbot. The main experience is a decision queue, supported by an agent brief, document details, a transparent activity timeline, and clear approval controls.

The application uses the following architecture:

Layer: Technology or approach: Frontend React 19 with a responsive dashboard interface API Type-safe procedures using tRPC Data layer PostgreSQL with Drizzle ORM File storage Amazon S3-compatible object storage Document processing Page-level text extraction with confidence information Agent orchestration Strands Agents SDK Model provider Claude Sonnet through Amazon Bedrock Safety boundary Server-enforced approval records and reconciliation checks Demonstration Synthetic insurance, school, and appointment documents

The agent is not given unrestricted access to the application. It operates through narrow tools for tasks such as reading document text, extracting obligations, calculating priority, creating or updating tasks, drafting responses, requesting approval, and recording audit events.

The agent decides how to interpret and phrase information. Deterministic application code decides what is allowed. Dates and amounts are normalized server-side, queue states are reconciled against persisted data, and draft execution is blocked unless a valid approval record exists.

Every major operation is also represented in the audit timeline. This includes upload, extraction, obligation detection, task creation, draft generation, approval, rejection, and simulated execution.

What we learned

The most valuable output of an agent is often not an answer

Our first instinct was to think about Triage as a document summarizer. That framing was too narrow. A summary still leaves the user with the responsibility of deciding what matters and what to do next.

The more useful output is a structured decision. A good agent should identify the deadline, the required action, the missing information, and the smallest decision that only the user can make.

Agent autonomy needs an explicit boundary

A prompt that says “ask for approval before sending” is not enough. The application must enforce the rule independently of the model.

This led us to treat approval as a persisted state with a payload snapshot, content hash, expiry, and audit event. If the approved content changes, the approval becomes invalid. If no valid approval exists, the execution path cannot continue.

Evidence makes extraction more trustworthy

A deadline or amount is much more useful when the user can see where it came from. Triage attaches source quotes and page references to extracted facts. This gives users a way to verify the agent’s work without rereading the entire document.

It also gives the system a safer fallback: when a fact is not present or confidence is too low, Triage can leave the value empty and ask for review rather than inventing an answer.

The user experience should expose decisions, not model activity

Users do not need to see every internal thought of an agent. They need to see what was found, why it matters, what will happen next, and what they must approve.

We therefore made the main interface a decision queue and used the tool trace and audit timeline as supporting transparency layers. This keeps the product understandable without hiding how the agent works.

Challenges we faced

Designing a useful workflow instead of another chatbot

The biggest product challenge was avoiding a conversational interface that could answer questions but did not actually complete work. We designed the workflow around uploaded documents, persisted tasks, drafted actions, and explicit state transitions.

This made the project more demanding than a simple chat experience, but it also made the value visible in a short demonstration.

Separating model judgment from deterministic business rules

Document interpretation is naturally probabilistic. Priority calculation, deadline normalization, ownership checks, and approval enforcement should not be.

We addressed this by giving the Strands agent focused tools and keeping important invariants in application code. The model can propose structured information, but the server validates and reconciles the result before it reaches the decision queue.

Handling sensitive domains responsibly

Life-admin documents can contain information related to health, money, family, and legal obligations. Triage is designed as an administrative organization tool, not a medical, legal, tax, or financial advisor.

We use synthetic documents in the demo, keep the S3 bucket private, keep credentials server-side, avoid logging document contents, and label simulated execution clearly. These constraints shaped the product in a positive way: Triage prepares work while leaving consequential judgment and action with the user.

Building a credible demo under time pressure

A full production system would require identity management, provider-specific integrations, long-term retention policies, monitoring, backups, and a broader set of OCR providers. We prioritized the vertical slice that demonstrates the core idea end to end:

Plain Text

upload document → extract text → identify obligations → create decision queue item → draft response → require human approval → simulate execution → write audit event

This allowed us to demonstrate a real agent workflow without pretending that a hackathon prototype was already a fully deployed personal assistant.

Why it matters

Life admin consumes time and attention precisely because it is fragmented. It is spread across PDFs, email attachments, forms, letters, and reminders. The burden is not only reading; it is maintaining a mental model of what each document means and what must happen next.

Triage reduces that burden by converting unstructured paperwork into a small number of explicit decisions. It helps people spend less time locating and interpreting administrative information, while preserving control over actions that affect their lives.

The broader lesson is that useful personal agents should not be measured only by how much work they can perform autonomously. They should also be measured by how well they know when to stop, how clearly they explain their recommendations, and how reliably they preserve human control.

What we would build next

The next version would add verified identity management, production OCR for scanned documents, real email and calendar connectors, durable rate limiting, monitoring, backups, configurable retention, and user-controlled deletion. These additions would extend the existing approval boundary rather than bypass it.

The long-term goal is not to automate every decision. It is to remove the repetitive administrative work that surrounds decisions, so that people can focus their attention where it is actually needed.

Triage does not replace human judgment. It removes the administrative work required to reach it.

Built With

Share this project:

Updates

Submission history