Raji Punjabi

Meal planner / Independent project

Planning family meals with an agent

An agent that turns family feedback into a weekly meal plan, with a person reviewing it before anyone shops or cooks. I built it to make the coordination around dinner easier.

  1. Collect feedback

    Preferences, leftovers, and changing constraints

  2. Draft the plan

    A week of meals and recipes

  3. Review together

    A person checks the plan before it is used

    Human review

  4. Coordinate

    Turn the approved plan into practical instructions

  5. Shop and cook

    Use the plan through the week

  6. Carry feedback forward

    What worked and what to change next week

The weekly planning and review loop.

It started with a Google Doc

Planning family meals meant coordinating preferences, leftovers, recipes, and shopping. My wife, our nanny, and I all contributed feedback. The hard part was keeping that information useful from one week to the next.

I built the agent to connect planning with the practical work around it: collect feedback, draft the week, review it with a person, and turn that into a plan people could actually use.

The product is the loop, not the document

The system uses Claude Code alongside Google Docs, Apps Script, local scripts, and messaging integrations. Scheduled tasks coordinate the weekly work, with OAuth permissions and recovery mechanisms supporting access and execution.

A meal plan is only one output. The interaction spans several tools and several people, with changing context between runs. That made the review points and handoffs more important than creating a new standalone interface.

This is a personal coordination tool, not dietary or medical advice. People remain responsible for checking the plan and its suitability.

What breaks when an agent has to run unattended

Context needs boundaries
Preferences, leftovers, and dietary constraints are not interchangeable inputs. The system needs to carry the right context into the next plan without treating every old instruction as permanent.
Human review is part of the interaction
A generated plan is a proposal. The review step is an intentional decision point before people organize shopping and cooking around it.
A schedule is not a guarantee
Scheduled execution needs a way to detect a missed or failed run. Watchdogs, heartbeats, and recovery logic became part of making the weekly workflow dependable.
Permissions are product decisions
An agent working across documents and messages needs explicit boundaries. What it can read, what it can change, and when it needs a person are part of the experience.

Reliability is part of the experience

Building this agent made the surrounding system impossible to ignore. A good answer is not enough if the job doesn’t run, the context is stale, or nobody knows what needs review.

Designing an agent also means designing permissions, context, recovery, observability, and trust. Working on the software directly made those tradeoffs concrete.