# Metabolic Compute: Systems That Work While You Sleep

Most software is reactive. It sits idle until a request comes in, does the work, returns a response, goes back to sleep. A web server waiting for HTTP requests. A database waiting for queries. A function waiting to be called.

A living organism doesn't work this way. Even at rest, your body is digesting food, repairing cells, regulating temperature, consolidating memories, fighting infections. This background activity — metabolism — is what keeps the organism healthy and ready. You don't consciously decide to do it. It just happens, proportional to available resources.

What if software worked the same way?

## The Concept

Metabolic compute is a system that does useful background work during idle time, without being asked. Not scheduled batch jobs on a cron timer. Not event-driven reactions to triggers. Continuous, adaptive background processing that responds to the system's own state.

The key properties:

**1. Resource-proportional.** The system does more work when it has more idle capacity, less when it's busy serving requests. Like a body that digests faster at rest and slower during exercise.

**2. Pressure-responsive.** Constraints trigger action. Running low on storage? The system doesn't just warn you — it starts compressing files, converting formats, archiving cold data, identifying duplicates. The pressure itself is the signal.

**3. Self-improving.** The system gets better over time without intervention. Unprocessed scans get OCR'd. Uncategorized files get categorized. Gaps in knowledge get flagged. Each idle cycle leaves the system in better shape than before.

**4. Invisible.** The user doesn't manage it, schedule it, or think about it. They just notice that things are faster, cleaner, and more organized than they left them.

## What It Looks Like in Practice

### File Metabolism
- Scanned documents get OCR'd automatically during idle time
- Large files get compressed or converted to open formats
- Duplicate detection runs continuously — same file uploaded twice gets flagged
- Access patterns tracked — frequently accessed files stay hot, cold files get archived
- Storage pressure triggers progressive cleanup: compress first, archive next, flag for deletion last

### Data Metabolism
- Contacts without email addresses get flagged for enrichment
- Dead links get detected and marked
- Notes get auto-tagged based on content
- Related items get linked — a contact mentioned in a note gets associated
- Search indexes rebuild incrementally during quiet periods

### Intelligence Metabolism
- AI reviews chat logs and finds questions it couldn't answer well
- Gap detection creates tasks: "15 visitors asked about X — no content covers this"
- Weekly summaries generate themselves from activity data
- Reports that will be needed Monday morning run Saturday night
- The system literally gets smarter while you sleep

### Resource Metabolism
- Database queries get analyzed — slow ones get flagged or optimized
- Stale cache entries get pruned
- Expired sessions and tokens get cleaned
- Log files get rotated and compressed
- API response times get monitored — degradation triggers investigation

## Why This Is Different From Cron Jobs

A cron job runs on a fixed schedule regardless of system state. Metabolic compute is adaptive:

| Property | Cron Jobs | Metabolic Compute |
|----------|-----------|-------------------|
| Timing | Fixed schedule | Proportional to idle capacity |
| Trigger | Clock | System state and pressure |
| Priority | All equal | Responds to what matters most now |
| Awareness | None — runs blind | Knows what's already been processed |
| Adaptation | Static until changed | Learns what needs attention |

A cron job that compresses files at 3 AM doesn't know if storage is fine or critically low. It runs the same either way. Metabolic compute compresses aggressively when storage is tight and barely at all when there's plenty of room.

## The Architecture

In a system built on callable objects with persistent state, metabolic compute is straightforward:

1. **Each metabolic function is an object.** OCR processor, duplicate detector, link checker, gap analyzer — each is a self-contained Python object with its own state.

2. **A scheduler dispatches based on pressure.** Not a fixed timer, but a system that checks: what needs attention? What resources are available? What hasn't been processed yet?

3. **Objects track their own progress.** The OCR object knows which files it's processed and which are pending. It doesn't re-scan everything every cycle.

4. **Priority is dynamic.** Storage at 95%? File compression gets priority. New batch of scans uploaded? OCR jumps to the front. Nothing urgent? Run the link checker.

5. **Results feed back into the system.** OCR output becomes searchable text. Gap detection becomes tasks. Duplicate detection becomes cleanup suggestions. The metabolism's output is the system's improvement.

## The Economics

Metabolic compute turns idle resources from waste into value. You're already paying for the server to sit there at 3 AM. You're already paying for the database to be available. The marginal cost of using that idle capacity is nearly zero.

But the value compounds. Every file that gets processed during idle time is a file that doesn't need processing when someone requests it. Every gap that gets detected is a gap that gets filled before a customer notices it. Every duplicate that gets flagged is storage that gets reclaimed before you hit a limit.

Over time, a metabolic system is cheaper to run than a reactive one because it prevents the expensive emergencies — the storage crisis, the slow query at peak traffic, the customer question nobody can answer.

## Why Nobody Does This

Most systems are built by teams that own specific features. The file team builds file upload. The search team builds search. Nobody owns "the thing that runs in between everything else when nothing is happening." Metabolism is cross-cutting — it touches files, contacts, notes, search, billing, AI. No team has that scope.

Solo developers with AI assistance don't have this problem. One person already sees the whole system. AI can implement the metabolic functions. The objects system provides the runtime. The hard part — having full-stack visibility into what could be improved — is actually the natural state when one person built the whole thing.

## The Biological Parallel

This isn't just a metaphor. Biological metabolism has properties worth stealing:

- **Homeostasis**: The system maintains itself within operating parameters automatically
- **Prioritization**: Critical functions (heartbeat) never stop; optional functions (digestion) pause under stress
- **Repair**: Damaged or degraded components get fixed without conscious intervention
- **Growth**: During periods of abundance, the system invests in capacity for the future
- **Signaling**: Chemical signals (hormones) coordinate activity across subsystems — equivalent to events and message queues

A platform with metabolic compute doesn't just serve requests. It maintains itself, improves itself, and adapts to pressure — the way a living system does.

## Starting Point

You don't need to build the full metabolic system at once. Start with one function:

1. Pick the most obvious idle-time task (e.g., OCR unprocessed scans)
2. Build it as an object with persistent state tracking
3. Run it during low-traffic hours
4. Measure: did it save time when users actually needed that data?

Then add the next one. And the next. Each metabolic function makes the system a little more alive. Over time, the platform stops being software that waits for instructions and becomes software that takes care of itself.