Building an Agent That Notices Things (So You Don't Have To)

The problem with AI assistants

Most AI tools wait for you to ask. You type a prompt, it responds, you type another prompt. It's a glorified search box. The interaction is always: you initiate, it reacts.

That model breaks down when you're running a business. The things that kill you aren't the questions you remember to ask — they're the things you didn't notice. The opportunity you walked past. The metric that silently degraded. The relationship that went cold while you were busy with something else.

A real assistant doesn't wait to be asked. A real assistant notices things.

The shift: from tool to instrument of cognition

I spent the last month building an agent system that runs continuously — not as a chatbot, but as a set of autonomous daemons that observe state, form observations, and create their own work. The core architecture:

1. Initiative engine — runs every 4 hours. Reads system state (goal queue, cron health, session logs, vault drafts). Forms observations. Mints self-directed goals.

2. Trajectory crons — 6 scheduled jobs, each tied to a life trajectory (money, reputation, skills, health, network). They scan, extract, draft, and deliver without being asked.

3. Observation ledger — a persistent record of things the agent noticed. Each observation has a category, priority, and resolution state. The agent can resolve observations with quick actions.

4. Goal queue — a structured work queue that any agent in the fleet can pull from. Goals are typed (light/deep), categorized, and prioritized.

The key insight isn't the architecture — it's the posture. The agent doesn't just execute what you tell it. It looks at the state of your world and decides what needs doing.

What this looks like in practice

At 4am, the initiative engine runs. It checks:

Each of these becomes an observation. Each observation can generate a goal. Each goal goes into a queue that worker agents can execute.

The operator wakes up to a Telegram message with a compact summary: what was noticed, what was generated, what was resolved, how many goals are active. 15 lines. Not a dashboard. Not a notification stream. A report from someone who was watching while you slept.

The architecture pattern: closed-loop agents

The pattern that makes this work is what I call closed-loop agent design:

Observe → Form Observation → Generate Goal → Execute → Verify → Observe

Each step feeds the next. The agent doesn't just run a task — it runs a task, checks the result, and adjusts its model of the world based on what happened. This is different from cron-job thinking (run X every Y hours) and different from chat thinking (user says X, agent does X).

The closed loop is what prevents drift. Without it, you get agents that run but don't adapt. They execute the same scan even when the data source is blocked. They generate the same nudge even when the health data is stale. The loop forces the agent to notice when its own actions aren't working.

What went wrong

The first 24 hours of running this system taught me more than the build:

1. The money scanner is blind. 3 of 4 data sources (Acquire.com, Upwork, SAM.gov) require JavaScript rendering or block automated access. The cron runs, reports "no opportunities," and ships a clean status. But the status is lying — it's not that there are no opportunities, it's that the scanner can't see them. Lesson: "ran successfully" and "produced useful output" are different things.

2. The health nudge has no live data. It delivered a nudge based on a June 30 manual log, not live Apple Health data. The nudge was correct (sleep is below threshold) but the data pipeline doesn't exist. Lesson: an agent that gives the right answer for the wrong reason is still broken.

3. Goals accumulate faster than they're executed. The initiative engine minted 25 goals in 24 hours. Zero were completed by worker agents (there is no worker daemon yet). I had to cancel 12 as redundant or self-executed. Lesson: a goal queue without a consumer is just a guilt list.

The key insight

The difference between a tool and an employee isn't intelligence — it's initiative. A tool waits. An employee notices.

When you build an agent system, the first question is usually "what can it do?" The better question is "what does it notice?" If your agent can't observe the state of the world and form opinions about what matters, it doesn't matter how smart the response generation is.

Build agents that notice things. Everything else follows from that.


This post is based on 30 days of building and 24 hours of running a closed-loop agent fleet. The system is in production. The mistakes are real.