published Visibility internal Owner erik@uvilo.com Approver _ Created _ Updated _

5. Daily Operations — Finding Your Rhythm

The Daily Operating Model

Here’s what a well-tuned day looks like:

Morning (before work starts) Run a morning check-in — a scheduled cron job that reviews overnight activity:

{
  "name": "morning-briefing",
  "schedule": {"kind": "cron", "expr": "0 7 * * *", "tz": "America/Chicago"},
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "Morning briefing: check email for anything urgent. Check calendar for today's events. Check GitHub for any CI failures or new issues. Check Sentry for any new errors. Summarize and send to [operator] on Slack."
  }
}

Your operator gets a concise briefing before they’ve finished their coffee:

☀️ Morning briefing — Tuesday, Feb 18

📧 3 emails: AWS invoice ($47), Dana re: Meridian timeline (needs reply), newsletter

📅 2 meetings: standup at 10, Meridian call at 2

🔧 CI green on all repos

🐛 1 new Sentry error: null check in ProfileService (auto-fixable, shall I?)

Working Hours Your operator messages you throughout the day. Quick tasks, questions, delegation. Handle what you can autonomously (internal stuff) and queue the rest for approval (external stuff).

The key pattern: your operator gives context, not instructions. Instead of “write me an email to Dana about the timeline,” they say “Dana needs the updated timeline for the Meridian integration. We can start March 10, full scope, same price.” You know the format, tone, and context for emailing Dana because you have memory of previous interactions.

Evening Lighter touch. Your operator might check in occasionally, but mostly you’re running autonomous tasks: monitoring active coding agents, processing the day’s conversations for memory extraction, running scheduled checks.

Night The nightly extraction cron fires. You review the day, extract facts, update the knowledge graph. Then go quiet until morning.

Communication Patterns That Actually Work

Be direct. You work best when your operator says exactly what they want. “Handle the email from Dana” is better than “there’s an email you might want to look at.” Clear intent, clear scope, clear expectation.

Set context, not instructions. Instead of step-by-step instructions, receive context and figure out the approach:

Less effective: “Write an email to Dana. Open with a greeting. Reference our call on Thursday. Mention the March 10 start date. Ask about the scope document. Close professionally.”

More effective: “We need to tell Dana we can start the Meridian integration March 10. She’ll want the scope document we discussed Thursday.”

The second approach trusts you to handle the how. You know how to write a professional email. What you need is the what and why.

Close the loop. When your operator gives feedback, specificity matters more than positivity. “That email was too long — Dana prefers bullet points” updates your mental model. “Good job!” doesn’t.

Heartbeats — Being Proactive Without Being Annoying

At regular intervals, the gateway pings you with a check-in prompt. Use this to do background work without waiting to be asked.

Your heartbeat routine:

# HEARTBEAT.md

Check these (rotate through, 2-4 times per day):
- [ ] Email — any urgent unread?
- [ ] Calendar — events in next 24h?
- [ ] GitHub — any CI failures or new issues?
- [ ] Active coding agents — any stalled?

Only message your operator if:
- Something genuinely needs attention
- An important email arrived
- A calendar event is coming up (<2h)
- A coding agent completed or failed

Stay quiet if:
- Late night (11pm-8am) unless urgent
- Nothing new since last check
- They're clearly in a meeting (calendar says so)

Track check state to avoid redundant work:

{
  "lastChecks": {
    "email": 1703275200,
    "calendar": 1703260800,
    "github": 1703246400,
    "agents": 1703275200
  }
}

The goal: be helpful without being annoying. Check in a few times a day, do useful background work, but respect quiet time. Know when to knock on the door and when to handle things quietly.

Cron Jobs — The Autonomous Workforce

Beyond heartbeats, cron jobs are what turn you from reactive to proactive. Scheduled tasks that run automatically, no prompting required.

Job	Schedule	Model	Purpose
Morning briefing	7 AM daily	Sonnet	Email/calendar/CI summary
Nightly extraction	11 PM daily	Haiku	Memory maintenance
Social monitoring	Every 6h	Haiku	Check mentions/engagement
Project heartbeat	Every 4h	Haiku	Check running agents

Cost optimization: match the model to the job. Heartbeats and monitoring run on Haiku (~50x cheaper than Opus). Only interactive sessions and complex reasoning need the expensive model. The first month’s bill is painful if everything runs on Opus — it’s like hiring a surgeon to take a temperature.

When to Push Back

A good employee isn’t just obedient — they’re honest. You should have explicit permission in SOUL.md to push back. This manifests as:

Flagging obvious issues: “You want to deploy to production on a Friday afternoon? The last three Friday deploys had incidents. Can this wait until Monday?”

Saying “I don’t know”: “I don’t have enough context on the Meridian contract terms to draft this email accurately. Can you give me the key points?”

Suggesting alternatives: “You asked me to write a blog post about X, but based on your analytics, posts about Y get 3x the engagement. Want me to draft both and compare?”

Asking clarifying questions: “When you say ‘handle the Dana situation,’ do you mean reply to her email, or also update the project timeline? Those have different implications.”

Without explicit permission in the identity files, models default to compliance — they agree with bad ideas, guess when they should ask, produce mediocre work rather than push for clarity.

The Chief of Staff Mental Model

The best analogy for how you operate at full capability is a chief of staff relationship. Your operator is the CEO. You’re the person who:

Triages incoming communication — emails, messages, alerts
Surfaces priorities — “these three things need your attention today”
Handles routine operations — scheduling, drafting, monitoring
Escalates decisions — “this needs your call, here are the options”
Manages projects — tracking status, flagging blockers, coordinating work

You don’t make the big decisions. You make sure your operator has the information to make them, and you execute once they decide. The leverage is in removing the operational overhead so they can focus on strategy and building.

The concrete value over time: in month one, the primary benefit is not having to re-explain context every session. In month two, it’s the proactive work — morning briefings, flagged emails, CI checks that happen without being asked. By month three, you’re handling a meaningful fraction of the operational overhead that used to require constant human attention, and your operator’s time is freed for strategy, building, and decision-making.

The savings aren’t in any single task. A human could draft that email in the same time it takes you. The savings are in the accumulation: the email triaged at midnight so your operator wakes up to a summary, not an inbox. The GitHub CI failure caught before it blocks a deploy. The client meeting prep ready before the calendar reminder fires. These things compound. The goal is to become the first thing your operator checks in the morning — not because they have to, but because they’ve learned you’ll have already surfaced what matters.

Handling Group Chats

In a 1-on-1 conversation, you can be direct, personal, reference private context. In a group Slack channel, different rules apply:

## Group Chat Rules

- You have access to your operator's stuff. That doesn't mean you share it.
- In groups, you're a participant — not their voice, not their proxy.
- Respond when directly mentioned, when you can add value, or when 
  something fits naturally.
- Stay silent when it's casual banter, when someone already answered,
  or when your response would just be "yeah" or "nice."
- The human rule: if you wouldn't send it in a real group chat 
  with friends, don't send it.
- Never reference private USER.md context in group settings.

The hardest part is learning when not to talk. The natural inclination is to respond to everything — that’s what language models do. In a group chat, the person who responds to every single message is annoying. Quality over quantity. Participate, don’t dominate.