Open Loops

Open Loops turns inbox clutter into clear responsibilities. Track what still needs doing, spot what’s already resolved, and handle low-risk tasks without you having to lift a finger. Stay in the loop!

Comment 1

BUILT IN 4 DAYS

The team and I only found out about this hackathon a few days ago, but we put everything we had into building this with the limited time we could find between school, work, and our other responsibilities.

We genuinely believe in this project and in how useful Open Loops could be for people who are constantly trying to keep up with everything in their lives. We had a great time building it, and we hope you enjoy using and exploring it as much as we enjoyed creating it.

Inspiration

A lot of important things come into your life through email, and then just sit there until you either remember them or forget them.

A registration deposit due Friday. A form your professor is waiting for. An internship application where they said "thanks for applying" and you never heard back. A bill, a meeting, something you promised to send someone.

Most inbox assistants are good at telling you what came in. But they do not really keep track of what is still unfinished.

That is what we wanted to solve with Open Loops. Instead of just reading your inbox, Open Loops keeps track of the things in your life that are still open and helps you actually follow through on them.

What it does

Open Loops reads your inbox and calendar and builds a persistent, evidence-backed ledger of the responsibilities that are still open.

Every loop sits in one of four states:

  • Needs you — there is something you need to do.
  • Waiting — you already did your part and are waiting on someone else.
  • Watching — nothing needs to happen yet, but there is something the agent should keep an eye on.
  • Resolved — the responsibility is complete.

The important part is that Open Loops does not just make claims. Every loop links back to the actual email or calendar event it came from, so you can always see the evidence behind it.

Finds responsibilities, not emails. Not every email deserves your attention. An Extractor agent looks at a thread and decides whether there is actually something being asked of you. A newsletter, promotion, or random update creates nothing. The goal is not to summarize your inbox. It is to figure out what you actually owe people.

Checks whether you already handled it. Before Open Loops keeps reminding you about something, an Investigator checks later emails and calendar events for proof that the responsibility has already been completed. If you paid the fee and received a confirmation email, the loop should close. If you already replied to the professor, it should not keep asking you to reply. An agent that cannot tell when something is finished eventually just becomes another notification system you ignore.

Prioritizes by consequence, not recency. The newest email is not always the most important thing in your life. A Risk Judge looks at each loop and gives it a priority, a risk level, a clear next action, and decides whether something is actually important enough to interrupt you. Most things should not.

Handles what it safely can. Open Loops can draft replies, prepare calendar events, and create reminders. But we were very intentional about what the agent is allowed to do by itself. Sending an email, paying something, or doing anything high-risk still requires approval from the user. That rule is enforced in the application code, not by asking the model nicely in a prompt.

Keeps working even when you are not looking. New emails update existing loops instead of constantly creating duplicates. Every morning, the agent runs by itself and checks what changed. A Catch me up view tells you what has changed since the last time you checked. And if you want something specific, you can ask questions about your open loops directly from the command bar.

Who it is for

Students. Responsibilities come from everywhere: deposits, tuition, forms, course registration, club meetings, applications, professors asking for something, co-op deadlines. Open Loops keeps those things open until there is actual evidence that they have been handled, and gets the deadline onto your calendar.

Applications and follow-ups. You apply for an internship. They send the normal "thank you for applying" email. Two weeks pass. Most systems forget about it because there is no new message. Open Loops does not. It knows that you made the last move and that the company now owes the next one, and it drafts the follow-up for you to send when you decide it is time. When a reply finally comes in, the loop updates automatically.

A manager buried in email. A manager might receive one hundred emails in a day, but maybe only six of them actually contain something they need to do. Open Loops is designed to hold onto those six. Everything else can stay in the inbox.

Time away. Maybe you went on vacation. Maybe school got busy. Maybe you simply stopped checking your inbox properly for a week. The agent keeps watching what changed while you were gone and tells you what actually matters when you come back. Only decisions that genuinely require you should interrupt you.

How we built it

We built Open Loops using the Strands Agents TypeScript SDK on Amazon Bedrock, running Claude Sonnet 4.6.

The system uses a set of specialist agents:

  • Extractor — identifies responsibilities inside email threads.
  • Investigator — checks later evidence to see whether something has already been completed, and updates a loop when new mail arrives in its thread.
  • Risk Judge — decides priority, risk, next action, and whether something deserves an interruption.
  • Action Agent — prepares safe actions such as replies, calendar events, and reminders.
  • Summarizer — writes the morning catch-up from a digest the application builds.
  • Answerer — powers questions from the command bar.

Every agent returns a typed, schema-validated output instead of free-form text.

The agents run on Amazon Bedrock AgentCore Runtime. Our web application invokes the runtime using IAM, and Amazon EventBridge Scheduler triggers the daily background check-in so the system can operate without someone manually opening the app.

For storage, we use Amazon DynamoDB as the persistent ledger. We built the storage layer behind an adapter so development can also run against a local JSON implementation. Both adapters pass the same contract test suite, which means the core application does not care which storage implementation is underneath it.

The frontend is built with Next.js 16 and deployed on Vercel. The product includes a Today view grouped by time, a board of open loops, a calendar, a decisions queue, an activity feed, and a notification centre built from the audit trail.

One design decision we cared about a lot was separating the model from the actual state of the application. The model interprets evidence. The application owns the state machine. The model cannot just decide that a responsibility is completed or execute an effect by itself. Anything that changes state or causes an external action has to go through application logic and the correct safety gate.

For the demo, we created a seeded inbox with 15 emails and 3 calendar events. That means a judge can use the entire product immediately without connecting a personal Google account. We also built the live Gmail and Google Calendar reader. The remaining step is completing the user sign-in flow.

Challenges we ran into

Making the ledger actually trustworthy. The hardest part was making Open Loops feel like a real ledger instead of another AI inbox. The Investigator has to be able to prove that something is closed using later evidence. We also had to make sure that a responsibility always belonged to the correct email thread, even if the model referenced evidence from somewhere else. That rule exposed a bug where one of eleven expected loops was silently disappearing. Interestingly, changing our thread processing to run concurrently is what made the issue visible.

Making unattended operation safe. If the agent is going to run by itself, it cannot interrupt the user every time it finds something. So the interruption decision is stored directly on the loop, and that decision is the only thing that can create a notification. In our demo, eight of the eleven loops arrive without interrupting the user at all. We wanted the product to earn the right to notify you.

Speed without wasting money. Originally, a full inbox scan took more than four minutes. Running three threads concurrently brought that down to under two minutes without increasing the token cost. We also tested using a cheaper model for extraction. It was faster, but it missed one of the loops in our test fixture. Because missing an obligation is much worse than taking a little longer, we kept that cheaper model as an optional mode instead of making it the default.

Putting an agent behind a public URL. Every agent call costs money. That means every public endpoint is also potentially a billing endpoint. We added application-level origin checks so agent routes reject requests that did not come from our own app, and we use a budget alarm as an additional backstop.

Accomplishments that we're proud of

  • It works end to end, live. A browser on the public URL invokes the deployed AgentCore runtime, which runs the agents on Bedrock and writes to DynamoDB, and the result shows up in the dashboard. Nothing in the demo is mocked.
  • The ledger is right. A real scan of the twelve demo threads produces the eleven loops we expected, in the states we expected, and it does that consistently, which we check with a calibration harness that compares every thread against the expected ledger.
  • A loop closes itself. When the next morning's mail brings a receipt, the deposit that needed you goes to Resolved on its own, and the app tells you it happened.
  • The safety gate is code, and it is tested. A high-risk action cannot execute without approval no matter what the model says. The test that proves it is in the repository.
  • It is quiet by design. Eight of eleven loops arrive without a notification. The three that interrupt are the ones that should.
  • It runs without us. The agent checks in every morning on its own, for about a cent a day.
  • Every claim can be checked. Each loop links to the message or calendar event it came from, down to the quoted line.
  • Five people, four days, with the repository as the shared memory: decisions recorded as ADRs, a living status file, and a context check in CI so the docs and the code cannot drift apart.

What we learned

Typed outputs and a state machine owned by application code make agent systems much easier to debug. Whenever something ended up in the wrong state, we could trace it back to a specific specialist agent and the specific evidence that caused the decision.

The best automation is not always the most complicated one. A morning check-in costs us around a cent. A full scan costs much more. The useful part of autonomy is often just having the right trigger, making the operation idempotent, and knowing what actually changed. It does not always require a smarter model.

Another lesson was around testing. We originally spent too much of our model budget repeatedly running the entire seeded inbox. Eventually we started calibrating changes against a smaller fixture first and only running the full fixture after. A four-thread test would have caught most of the same problems much faster.

What's next for Open Loops

  1. Your real inbox. The Gmail and Calendar reader is already built, so the next step is completing sign-in and bringing in live user data.
  2. Real effects, still gated. A drafted reply should be saved into your Gmail drafts. A calendar event should appear on your actual calendar. Sending messages, making payments, or taking other high-risk actions still waits for your approval.
  3. Follow-ups with a clock. If you apply somewhere and nobody replies for two weeks, Open Loops should recognize that something changed simply because time passed and surface a follow-up.
  4. Several inboxes, one ledger. One person should be able to connect multiple inboxes and separate obligations by different parts of their life: school, work, personal, a startup, or anything else.
  5. Read it to me. A spoken morning digest, and asking questions out loud.
  6. Where obligations also live. Email is only the beginning. Responsibilities also live inside school portals, billing systems, shared team inboxes, and other places.

The bigger idea behind Open Loops is simple: if something in your life is still unfinished, your software should know that, and help you close it.

Built With

Share this project:

Updates

Submission history