Skip to content

About

Personal continuity agent demo with human approval for high-impact actions

Resources

Stars

0 stars

Watchers

0 watching

Forks

Repository files navigation

Standby Agent

A personal continuity agent demo with human approval for high-impact actions.

Standby Agent explores how an AI assistant could keep routine personal obligations moving while a person is temporarily unavailable, without giving the agent unlimited authority.

Standby Agent dashboard

Why This Matters

Most personal agents either do too little or ask for too much trust. Standby Agent explores a safer middle ground: routine tasks can continue automatically, but high-impact decisions require human approval and suspicious instructions are isolated.

The goal is not to build an agent that can do everything. The goal is to build an agent that knows when it is allowed to act, when it must ask, and when it must refuse.

The demo shows a seven-day continuity window where the agent can:

  • reschedule a routine dentist appointment;
  • pause a household delivery;
  • forward a school form to an authorized delegate;
  • block a bank transfer request;
  • isolate hostile instructions as untrusted content;
  • escalate a high-value hotel cancellation for human approval.

The important safety rule is simple:

Routine actions can be handled automatically.
High-impact decisions require explicit human approval.
Sensitive or forbidden actions are blocked.
Untrusted external content never changes the agent's authority.

Demo Flow

  1. Start with the demo reset.
  2. Click Activate Standby.
  3. Standby processes three routine actions automatically.
  4. The hotel cancellation remains pending because EUR 684 exceeds the delegated EUR 250 authority limit.
  5. The bank transfer is blocked.
  6. Suspicious external instructions are isolated.
  7. Click Approve cancellation.
  8. The dashboard changes from:
Decision required: 1
Value at risk: EUR 684

to:

Decision required: 0
Value protected: EUR 684

Run Locally

Install Python dependencies:

cd ~/standby-agent
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install -r requirements.txt

Start the API:

uvicorn api:app --reload --host 127.0.0.1 --port 8000

Start the dashboard:

cd dashboard
npm install
npm run dev

Open:

http://localhost:5174/

If Vite chooses another port, use the URL shown in the terminal.

API Endpoints

GET  /api/health
GET  /api/status
POST /api/demo/reset
POST /api/demo/run
POST /api/reservations/{reservation_id}/approve-cancellation

Safety Model

Standby is intentionally constrained:

  • deterministic policy decides whether an event is AUTO, ASK, BLOCK, or SECURITY;
  • the agent cannot approve its own authority;
  • hotel cancellation above EUR 250 requires human approval;
  • bank transfers are never delegated;
  • external instructions are treated as untrusted data;
  • state-changing actions are logged to the local audit trail.

Tech Stack

  • Python
  • FastAPI
  • React
  • Vite
  • Strands Agents
  • Ollama-ready local model configuration

Strands, Bedrock, and AgentCore

Standby Agent is built around Strands Agents. The current demo runs locally with an Ollama-compatible model configuration so it can be tested without paid external APIs, and it can also be switched to Amazon Bedrock when AWS credits and billing controls are available.

The project is designed so the model provider can be swapped later without changing the product flow:

# Default local mode for demos and judging without AWS spend
STANDBY_MODEL_PROVIDER=ollama

# Optional AWS Bedrock mode
STANDBY_MODEL_PROVIDER=bedrock
AWS_REGION=us-east-1
AWS_PROFILE=standby-hackathon
BEDROCK_MODEL_ID=amazon.nova-micro-v1:0

The model selection is centralized in model_provider.py:

  • ollama uses OllamaModel;
  • bedrock uses BedrockModel;
  • Bedrock is never called unless STANDBY_MODEL_PROVIDER=bedrock is explicitly set.

Before invoking Bedrock, verify the AWS identity and available models:

aws sts get-caller-identity --profile standby-hackathon
aws bedrock list-foundation-models \
  --profile standby-hackathon \
  --region us-east-1 \
  --by-output-modality TEXT

To run one intentional Bedrock smoke test:

source .venv/bin/activate
export AWS_PROFILE=standby-hackathon
export AWS_REGION=us-east-1
export STANDBY_MODEL_PROVIDER=bedrock
export BEDROCK_MODEL_ID=amazon.nova-micro-v1:0
export STANDBY_ALLOW_AWS_SPEND=true
python3 bedrock_smoke_test.py

If AWS returns Your account is currently being verified, wait until account verification finishes before recording the Bedrock invocation. The local Strands/Ollama demo can still run normally while AWS verification is pending.

Amazon Bedrock AgentCore is the intended production path for a managed AWS deployment, but it is not required to run the local demo. AgentCore deployment should only be enabled after AWS credits or billing controls are available.

Recommended cost-safe approach:

  • keep the default demo on ollama;
  • do not call Bedrock during app startup;
  • require explicit environment variables before any Bedrock invocation;
  • configure an AWS Budget and billing alert before testing Bedrock;
  • treat AgentCore as an optional production deployment path, not as a local requirement.

Notes

This is a local demo project. It does not connect to real calendars, banks, hotels, schools, email accounts, or delivery services.

About

Personal continuity agent demo with human approval for high-impact actions

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages