Managing recurring bills is something almost everyone has to deal with, but the process is still surprisingly manual. We constantly check what is due, compare amounts, make payments, and decide whether something looks unusual.

I wanted to explore what would happen if an AI agent could take over that repetitive work. But that immediately raised a bigger question: should an AI really have unrestricted control over someone's money?

That question became the foundation of LifeOps.

Instead of building an agent that simply pays whatever it finds, I wanted to create one that could operate autonomously within clearly defined boundaries. Routine financial tasks should happen quietly in the background, while unusual or high-risk decisions should come back to the human.

That led to the core principle behind LifeOps:

AI decides what should happen. Deterministic controls decide what is allowed to happen.


What LifeOps Does

LifeOps is an autonomous financial operations agent for managing recurring financial obligations.

It discovers upcoming bills, investigates previous spending, evaluates each obligation against financial safety rules, and determines what action should be taken.

In the demonstration, LifeOps manages three obligations:

  • Electricity Bill — ₦185,000
  • Internet Subscription — ₦25,000
  • Netflix — ₦7,000

The Internet and Netflix payments fall within the configured safety limits, so LifeOps handles them automatically.

The Electricity Bill is different. Previous Electricity payments averaged approximately ₦127,667, while the new bill is ₦185,000 — roughly 44.9% higher. It also exceeds the ₦100,000 automatic-payment limit.

LifeOps therefore returns:

NEEDS_APPROVAL

Instead of paying it, the agent escalates the decision to the user. Only after the user selects Approve & Pay can the transaction proceed.

This creates what I describe as bounded autonomy: the agent has enough authority to remove repetitive work, but not enough authority to bypass financial safeguards.


How I Built It

LifeOps uses Strands Agents as the autonomous orchestration layer and Amazon Bedrock for model reasoning.

The agent works through a controlled set of tools:

get_upcoming_tasks → get_bill_history → evaluate_bill_policy → record_decision → execute_payment → generate_financial_report

The LLM can reason about the workflow and decide which tools to use, but sensitive financial rules are implemented deterministically outside the model.

The payment layer independently verifies the persisted decision before executing a simulated transaction. A bill marked NEEDS_APPROVAL cannot be paid automatically, and the agent itself cannot create the human APPROVED state.

The rest of the application includes:

  • FastAPI for the backend API
  • SQLite for local state and transaction history
  • HTML, CSS and JavaScript for the interactive dashboard
  • Pytest for automated testing
  • Amazon Bedrock AgentCore for cloud agent deployment
  • Amazon CloudWatch / AgentCore traces for observability

I also deployed a public version of the dashboard so the complete workflow can be experienced without setting up the development environment locally.


Challenges I Faced

One of the biggest challenges was balancing autonomy with safety.

It would have been much easier to let the LLM determine whether a payment should proceed. Instead, I separated reasoning from authority. The agent can investigate, reason, orchestrate tools and recommend actions, but deterministic controls remain responsible for financial authorization.

Another challenge was maintaining the correct sequence of operations. A payment must never execute before its corresponding decision has been persisted. This required making financial mutations sequential and adding duplicate-payment protection.

Deploying the agent to Amazon Bedrock AgentCore introduced additional challenges around AWS authentication, IAM permissions, model access, packaging and cloud-runtime configuration. Adding observability also helped me understand how important traceability becomes once an AI agent starts taking actions rather than simply generating responses.


What I Learned

The biggest lesson I learned is that building useful AI agents is not just about making the model more capable.

It is also about deciding where the model's authority should end.

For sensitive systems, deterministic software can provide boundaries around probabilistic AI reasoning. Human approval can then become an intentional part of the architecture rather than a fallback when automation fails.

I also gained practical experience working with Strands Agents, Amazon Bedrock, AgentCore, FastAPI, tool-based agent orchestration, AWS IAM, cloud deployment, observability, testing and human-in-the-loop workflows.

Most importantly, LifeOps changed how I think about autonomous agents.

The goal shouldn't always be to remove the human completely.

Sometimes the better system is one that handles the routine quietly and knows exactly when to bring the human back in.


What's Next

The current LifeOps prototype uses simulated financial transactions, but the architecture could eventually support real billing and payment-provider integrations.

Future versions could include bank and utility integrations, automatic obligation discovery, configurable spending policies, notifications, fraud detection, budget awareness and adaptive recommendations based on changing spending patterns.

LifeOps could also suggest adjustments to financial limits as spending patterns or economic conditions change. However, following the project's safety philosophy, the agent would recommend those changes rather than silently rewriting the rules that constrain its own authority.

The long-term vision is simple:

Let AI handle the routine. Keep humans in control of the risk.

Built With

Share this project:

Updates

Submission history