Inspiration

Personal obligations rarely live in one clean task list. They get scattered across notes, to-dos, and documents, often with duplicated details, conflicting dates, or missing context.

I wanted to build an agent that does not require the user to organize everything first. Instead, Loose Ends Agent treats that scattered information as its input, reconciles related fragments, preserves where each fact came from, and asks the user only when genuine human judgment is required.

What it does

Loose Ends Agent is a local-first personal obligation reconciler.

It scans local notes and to-do data, identifies unfinished obligations, connects related evidence, and turns sufficiently grounded items into concrete next actions.

The important boundary is ambiguity.

If the agent encounters conflicting evidence, it does not silently choose an answer. It pauses through a real Strands human-in-the-loop interrupt, presents the conflicting evidence to the user, accepts the decision, and resumes the same agent session.

In the demo, two records contain different passport-renewal deadlines: September 30 and October 1. The agent detects the conflict, pauses, asks the user which deadline is correct, then resumes after the user selects September 30 and produces a grounded ready action.

How I built it

The orchestration layer is a real Strands Agent.

The agent dynamically chooses among evidence and action tools rather than following a fixed scripted sequence. The browser interface is backed by a Starlette RunManager, which preserves one live Strands session across the human interrupt and resume cycle.

The current local stack includes:

  • Strands Agents SDK
  • Python
  • Starlette
  • Ollama
  • qwen3:14b
  • Vanilla HTML, CSS, and JavaScript
  • Structured in-memory workspace state
  • Local notes and to-do fixtures

The agent uses tools for source scanning, evidence association, loose-end creation, action creation, provenance tracking, human-decision requests, and completion logging.

Deterministic Python guards enforce important safety boundaries around provenance, dates, evidence relationships, action grounding, and completion. This allows the model to decide what to do while preventing unsupported actions from being accepted.

Human-in-the-loop behavior

Human judgment is part of the execution model, not just a UI label.

When conflicting passport deadlines are found, the agent calls the Strands interrupt mechanism and the run enters a paused state.

After the user selects the correct date:

  1. the interrupt response is submitted,
  2. the same live Strands agent session resumes,
  3. the agent continues reasoning with the human decision,
  4. a grounded ready action is produced,
  5. the run reaches a truthful completed state.

The verified browser run completed with two agent invocations and one resume.

Challenges

The hardest part was not extracting tasks. It was making reconciliation safe.

Early runs exposed several failure modes that are easy to hide in agent demos: unsupported dates, unrelated evidence being merged, actions created before conflicts were resolved, and smaller local models entering retry loops.

I added deterministic contracts around tool calls and state transitions so the system rejects unsupported actions instead of presenting them as success.

Another challenge was local-model reliability. Smaller models could call tools, but were less consistent in longer multi-step flows. qwen3:14b became the judge-facing local model because it produced a much more reliable end-to-end run on the same workflow.

What I learned

I learned that useful human-in-the-loop behavior is more than asking a question.

The system also needs to preserve state, preserve provenance, associate the answer with the correct obligation, resume the same execution context, and refuse to claim completion while unresolved evidence remains.

The strongest design decision in Loose Ends Agent became the boundary between what the agent may safely resolve and what must remain a human decision.

What's next

The current submission intentionally focuses on a narrow, verifiable workflow.

Future versions could expand the source adapters, support more persistent storage, improve model/provider flexibility, and reconcile larger collections of personal obligations while keeping the same provenance-first and human-judgment boundaries.

Built With

Share this project:

Updates

Submission history