As part of my work, I pay for two AI subscriptions, Claude and ChatGPT. On a busy day, I run several AI sessions open at once: one for communication related tasks such as newsletters, another for data analysis such as usage patterns, behavioral analysis and the last one for product work such as docs, prototype etc. I experienced several challenges with this approach. For example, when i switch between Claude or ChatGPT application because I am running low on subscription tokens, I lose all past learnings.

I wanted a workflow where my work can continue irrespective of what models I use. I wanted an agent that will know how to retain my work related memory, provide the necessary context to a specific model based on the task scope/complexity and automatically reflect on my past week and send me a retrospective. I wanted this agent to simply handover each task to the right model, watch it, and tell me only when something needed me.

Why I didn’t use firstmate as is

Initially, I explored firstmate, an open-source agent setup for running a crew of coding agents. You talk to one agent, the first mate. It starts workers in their own terminal tabs, supervises them, and brings back finished pull requests. Every worker gets its own git copy of the repo, so parallel workers never collide. This setup would work well if I am coding all day, but my PM work doesn’t live in git that way. So, I decided to build a small version for PM work and borrow only the ideas I needed.

I call my agent pmmate.

What pmmate does

I talk to pmmate. pmmate routes, supervises all my tasks and finally reports on the progress of each task, and never does the work itself.

1. Each task runs in its own herdr tab, so I can watch any worker.

2. A small script waits for a worker to write a status line, so the supervising agent spends no tokens while it waits.

3. Everything is saved on disk, so a restart picks up where it left off.

The new idea is lanes. Each of my ten workstreams is a lane. For example, my lanes typically cover a) product strategy and roadmap, b) product pricing, c) prototype related work, d) customer and broad newsletter communication, e) data analysis and so on. A lane runs one worker at a time, because workers in one workstream share a STATUS.md file that tracks what’s live. Different lanes run in parallel. Workers edit the real folders, so they see the decks and inputs.

How it splits work across my two subscriptions

For every task, pmmate picks a tool and a model and writes down why so we can audit and improve it later. The rules I have now are simple and short:

• Hardest writing such as product strategy or pricing proposals and executive memos, choose Claude Fable 5.1 at high effort.

• Standard writing, such as the newsletter, product updates and RFP answers, choose Claude Opus 5.5.

• Mechanical edits, choose Claude Haiku 4.5.

• Product mocks or prototypes or data analysis on customer support tickets, product usage patterns, etc, using tools such as Python/SQL then choose Codex with Luna.

Before launching a worker, my pmmate tool checks for the subsription status to see how many tokens remaining of each subscription’s weekly limit is left and then routes the task according to the above rules. If the preferred model is below 15%, then pmmate moves to the next option and tells me. If in case, I explicitly say “use codex”, then pmmate overrides my choice.

What I learned building it

• Each worker takes one assignment and exits. If it has a question, it stops and pmmate asks me.

• I gave up steering a worker mid-task in exchange for supervision that is simple and reliable.

• Every commit uses a conventional commit message, so git log --oneline is the changelog.

• A README and a handoff doc cover the rest, so a new agent can pick up the project with full context.

How it reflects and improves

Each finished task adds one line to an outcomes log: the lane, the model, the minutes, whether I accepted it or sent it back, and my correction in my own words.

A /retro command reads that log. It reports what went well, and it turns any correction I make twice into a proposed change to a skill or a routing rule, shown as a diff. I approve each change. Nothing edits itself.

I write the skills using Matt Pocock’s rules - one skill per repeated steering with the front matter setup so that the skill is loaded only when needed, clear and specific steps in the skill file and separate reference section.

I have setup so that pmmate’s six skills are only 9 to 12 lines each and a skill change counts as working only when the correction it targets is addressed in the next week’s retro.

What am I looking forward to

• Route real code and data tasks through the Codex lanes, so the split isn’t all Claude.

• Run /retro after a week and see which corrections repeat.

I expect to keep paying for both subscriptions. What I’m looking forward to evaluating is whether an agent can put my tokens to better use than how I did.

For all multiple subscribers, I am curious to know on how you all decide as to which AI subscription gets which task?

In product management, a target user segment is a specific, defined group of users or customers with a common need that the product is designed to serve. Instead of building a product for “everyone,” a Product Manager (PM) narrows focus to a subset of the market that shares similar characteristics, needs, pain points, or behaviors.

Defining a target segment ensures the product solves problems for a highly motivated group of users, preventing wasted engineering resources on features nobody wants.

Take a growing B2B company with three promising requests. One prospect wants a new channel (say updates over Teams), another needs a different workflow, and a third asks for a different user experience.

A few years ago, engineering capacity forced a choice among them. With coding agents, the team may be able to build all three. So, should it?

I would still say no, or at least not yet, because building the feature was only the part of the commitment that used to be scarce.

When the sales team brings a request, it might look like a feature, but it is up to PMs to decide whether the request serves existing user segments or opens into a new user segment.

A new channel usually brings a buyer you have not previously sold to, and that buyer needs their own demo and their own proof of value. When you build a different workflow (say you bring agents into the workflow), then you serve a different job, so the team gets judged on new success metrics and against a new set of competitors. A different deployment model or user experience triggers its own review and integration work, and it often needs a separate sales motion.

AI cut the cost of writing the code, but it did not reduce the cost to:

• Get a prospect to believe the product works for their job

• Build the demo, integration, and reference story so the sales team can reuse it

• Support the edge cases once the deal goes live

• Offer a coherent roadmap that a team can explain without a footnote

If the company accepts all requests without thinking about the impact, then it will drift into different segments. Sales will now carry different stories. Similarly, support will manage unrelated sets of edge cases, and the team will spend the next quarter switching context when it could have made one workflow better than the alternatives.

Competitors can also copy features faster now. When a competitor can reproduce your dashboard in a sprint, the key difference comes from how well you truly understand your users’ needs and how well you serve the job-to-be-done for them.

This is why it is important for PMs to make your product positioning (how you want customers to perceive you) clear to Sales and the rest of the company. The team can then use it as a filter before it builds a requested feature.

A one-sentence test for each request

Before treating a request as roadmap input, write your current position in one sentence:

We help [buyer/user] do [job] better than [alternative], proven by [outcome].

Then put the each of the incoming sales/customer feature requests next to the above sentence.

• Same buyer, same job, better proof: build it. Most of the AI speed should be applied here, so your team can iterate faster and double down on your target segment.

• Same buyer, adjacent job: sequence it. You need to evaluate whether you are done or want to pause the current job-to-be-done before you open a new job for your target segment. This should be done after some thinking about the opportunities, users’s needs etc.

• Different buyer, different job, or a different way of buying: treat it as a new segment and decide it at that level, outside the feature backlog.

If you cannot write the above sentence, then you do not have a position yet, and building all three requests - just because your team can - will not get you anywhere.

Saying No

As a Product Manager, it is your job to say No. However, when you can clearly articulate the rule and framework, then Saying no becomes lot easier to the prospects.

When you identify requests that belong to other segments, log them clearly as new segment bets and assign an owner and a review date, so your teams and stakeholders know how you are thinking about this.

Before you say yes to a sales or customer request, try to answer these five questions:

1. Who is the buyer, and is it the buyer you already sell to?

2. What does success look like in the first 30 days, in their metric?

3. What demo, integration, and security review does this add?

4. Can the current sales story work well with this, or does it need a new one?

5. What will you stop doing to pay for the added support and roadmap work?

When you answer these questions and realize that solving your users’ or sales ask takes you away from your current buyer and sales story, then you are choosing either a new or an adjacent market, and you should run the request through the same review lens as you would use for entering a new segment.

When engineering capacity used to be common constraint, product teams didn’t having to explicitly make such decisions. With coding agents, the product teams must now make it on purpose.

I encourage the product teams to dig deep into the segment you already serve, and open up an adjacent or a new segment only after you have validation that you have differentiated value and a path to a repeatable sales motion in this new target segment.

Then, earlier this week, Amazon blocked Muse from shopping on its website.

Amazon said it had not authorized Muse to access customer accounts, collect information, or process transactions. It also said that third-party applications acting for customers should identify themselves and respect the service provider’s decision about whether to participate. (Source: Axios)

When I read this, I realized that I had been thinking about only one side of agentic commerce. I had focused on whether I trusted the agent. However, the merchant also has a vote in this.

Let us say that I ask Muse to find a pair of running shoes under $150, compare the options, and buy the pair that best matches my preferences.

I can give Muse permission to act for me. However, Amazon must recognize that delegation, allow Muse to use my account, and process the transaction. It also needs to know that Muse is staying within the authority I gave it. So, the purchase now depends on three parties:

• I need to trust Muse with my preferences, account, and money.

• Muse needs to complete the task correctly and stay within my instructions.

• Amazon needs to recognize Muse as an authorized agent and decide what it can do.

Any one of the above 3 parties can stop the purchase. What it also tells you is that browser access does not give the agent permission to complete any merchant transcations.

I had assumed that once an agent successfully mastered the browser access and received my trust, it could transact for me. Amazon’s block on Muse shows why that assumption is wrong.

A browser gives Muse technical access to a website. It does not give Muse permission to use the merchant’s services.

In my previous post, I described a trust ladder that agent will need to earn and this trust starts with successfully completing public web searches and gradually moves toward account access, messages, bookings, and purchases. Amazon’s decision adds another ladder. Even after Muse earns my trust, it must earn access from every merchant or service it wants to use.

This is why I found a recent Cloudflare change interesting. Website owners can now create separate policies for search crawlers, AI training crawlers, and agents acting for a user. If I ask Muse to visit a store, that request is different from a crawler collecting the store’s pages for search or model training. However, the merchant still needs a way to recognize the difference. (Source: Cloudflare)

Without that recognition, Muse may compare products across five stores, purchase from two, and then hand the task back to me for the other three. I asked it to complete one shopping task, but I still have to finish part of the checkout myself.

Agentic commerce needs a common language

Today, agentic commerce works best when a few companies decide to work together.

OpenAI and Stripe created the Agentic Commerce Protocol to support purchases inside ChatGPT. Google and Shopify created the Universal Commerce Protocol, which covers product discovery, carts, checkout, and post-purchase support. Shopify is using it to connect merchants with ChatGPT, Copilot, Google AI Mode, and Gemini. (Stripe, Google, Shopify)

These protocols give participating agents and merchants a defined way to complete a purchase. However, a merchant cannot build and maintain a different integration for Muse, Grok Bot, ChatGPT, Gemini, and every agent that comes next.

The agent needs a standard way to identify itself, show that the customer authorized it, learn what the merchant permits, and ask for approval before a consequential action. The merchant needs to remain in control of the transaction, customer relationship, returns, and support.

The Universal Commerce Protocol is one attempt to establish that common language. The merchant remains the merchant of record and chooses which capabilities it supports. I believe this will make more merchants willing to participate because they do not have to treat every agent arriving through a browser as suspicious automation.

Why Amazon is being careful

Amazon has several reasons to control how an outside agent shops on its website.

First, Amazon has a large advertising business. It reported $68.6 billion in advertising-services revenue in 2025, including sponsored ads, display, and video advertising. If I ask Muse to find the best running shoes and it returns one recommendation, I may never see the sponsored listings that Amazon would have shown me. Muse now has more influence over which products reach me. (Source: Amazon 2025 annual report)

Amazon also needs to know whether the agent is actually acting for me. A Muse session that I authorized, a bot scraping prices, and a malicious agent trying to access customer accounts may all arrive through a browser. Amazon still has to deal with payment fraud, returns, refunds, seller disputes, and account security after the agent leaves.

Amazon is listed as a supporter of the Universal Commerce Protocol. So, I do not think Amazon is rejecting agentic commerce. I think it wants agents to use an agreed method to identify themselves, prove that the customer authorized the action, and follow Amazon’s transaction rules.

Prime still influences where I buy

I might let Muse buy something from Facebook Marketplace or compare concert tickets across several websites. However, for everyday physical products, I will probably continue choosing Amazon. With Prime, I can often place an order and receive it in less than 24 hours, and I know what to expect if I need to return it.

Muse may find the same product for a lower price elsewhere, but the lowest price is not always the best choice for me. Delivery speed and easy returns often matter more. So, if a shopping agent cannot access Amazon, it may finish the research and still miss the option I would have chosen.

This is also something agents need to learn about us. I may ask Muse to find the lowest price, but that is not the only rule I use. I may choose Amazon because I trust Prime delivery and returns, even when another store is cheaper. I may not state that preference because I make the decision almost automatically. If Muse is going to shop for me, it needs to learn from those choices instead of treating price as my only instruction.

What I will watch next

I still expect to let an agent buy things for me. However, I do not expect the agent to replace the merchant relationship I already have.

For physical goods, I want the agent to understand various nuances such as Prime delivery or a specific brand or vendor matters to me more, even when Amazon is not the cheapest option. For tickets or travel, I may care more about the seat, schedule, cancellation policy, or total price. The agent needs to infer and apply those preferences while staying within the authority I gave it.

For now, I will continue using Muse to research and compare products. The next test is whether it can work through a merchant-approved path, complete the purchase using my actual preferences, and help me if I need to cancel, return, or get a refund. That is when I will start letting it finish more purchases for me.

Msgvault

A while back I came across Msgvault, and started using this tool to keep a local copy of my whole Gmail. It pulls every message into a SQLite database on my Mac plus a folder of attachments, and it only reads from Gmail, never writes. Right now my local copy holds 173,206 messages and about 13,000 attachments, roughly 13GB.

So, my goal was to treat Gmail as the live account with a max size limit of (10 GB) and msgvault as the full archive on my own disk. This would allow me to delete the old, unwanted emails within my Gmail once the archive is complete and still keep everything in my local disk. However, I was worried that Msgvault on a future full-sync would try to delete my local archive copy to match with what is in the Gmail. I couldn’t find any documentation to explain how Msgvault worked and its behavior in such a scenario. My second concern was that I could not figure out how to automatically synchronize / back up my Gmail SQLite database to an external disk.

Agents to my rescue!

I asked my OpenClaw agent to investigate on my first concern: review the msgvault source code and docs and then tell me how Msgvault handles when I delete a message from Gmail, does the next msgvault sync remove the local copy?

I wanted my agent to answer from the real system, not from a guess. So it read msgvault’s source code and database schema. The agent found that Msgvault has a messages table with two columns, deleted_from_source_at and archived_at, which only make sense if the tool is built to keep a local message after it leaves Gmail and record when that happened. The docs said the same. This made it apparent that Msgvault’s default approach is to retain and not delete the local archived copy. This confirmation gave me confidence that I could built a workflow on top of Msgvault.

Agents figures out why my backup was broken

Now here is where things got interesting. My whole plan rested on one assumption - that my local archive was safely backed up on my external disks. So before deleting anything, I asked my agent to run a backup. Msgvault backup command threw some error messages. And when the agent dug in, it turned out the backup had been failing on every single run for a while now.

The culprit? 39 attachment files that were either corrupt or missing on disk. The backup would hit one of these bad files, choke, and stop. So the very safety net I was counting on had not been completing at all. Good thing I checked before I started deleting the originals, and not after.

My agent then found that msgvault quietly keeps a full raw copy of every message, compressed, stored separately from the loose attachment files. So the agent pulled the correct bytes for each of the 39 broken attachments out of that raw store, verified each one against its checksum to make sure it was rebuilding the exact original and not some garbage, and wrote it back. All 39 recovered, none lost. Then the backup ran clean to two separate external drives, and I had the agent verify both.

Now the deletion plan finally felt safe. I now have two clean backups on 2 external disks and I have also confirmed on the retention behavio with one test deletion gave me the confidence to now fully go ahead.

One more thing - Minor optimization

I decided to split my Msgvault archive so the agent could work on parts of it

First thing I wanted was to organize my archive so that I can build more agentic workflow on top of my emails before deleting any of the emails. In particular I wanted all my LinkedIn and Substack mails on their own, so an agent could read just that slice instead of my entire inbox.

I had the agent build a small carving script that takes a --profile and pulls a standalone searchable database out of the main archive for a chosen set of senders. LinkedIn came out as its own database, 27 senders and about 14,700 messages. Newsletters came out as another, 463 senders. Each one is a self-contained SQLite file an agent can open by itself.

Now on to automated deletion to save my GMail space

I leaned in on msgvault’s staged path to delete my Gmails.

Now, you might wonder - Hey, Sriram - all of these are done by the Msgvault tool. What did AI agents do here? Funny thing is that I guided my OpenClaw to optimize for safety and reliability. My agents found the best path forward. My agents read the Msgvault source and docs to figure out that using msgvault’s deletion flow is better rather than sending raw delete API calls to Gmail, because Msgvault has these specific gates that ensure automation does not accidentally delete or touch emails that you want retained.

• Stage the messages into a batch.

• Staging also saves each message’s full raw content locally first, so the archive copy is captured before the Gmail copy goes.

• Dry-run the batch to see what it would remove without removing anything.

• Execution only runs when a specific environment flag is set, so nothing deletes by accident.

Then, I asked it to pick messages that had the lowest signal. It started with the oldest LinkedIn job alerts, the least valuable mail in the account. Sorry, LinkedIn.

My agent staged one email for deletion first following the above workflow - first staged, then dry-run, and finally executed.

I now double checked that the local copy was not deleted. This gave me confirmation and I was ready to try bigger and more audacious things.

What you can take away from this

Yes, Msgvault tool is awesome and it makes it really easy to archive your GMail. Honestly that is not really the point. To me though, the reusable bit is how you can navigate your checks to do the due diligence and automate your every day tasks.

A few things I would do again. I made the agent write scripts to deterministically verify the safety behavior against the real system before it touched anything. I had my agent to also split my mail into slices so it could pick up one at a time, all behind a single engine instead of a pile of one-off scripts. Last but not least, I guided my agent so that deletions go through msgvault’s own staged, dry-runnable, gated path rather than raw API calls. Last but not least, I had my agent check that my backup actually worked before I relied on it, which is how I found out it had been quietly broken.

I was able to do one round of clean up. I have reduced my GMail to now 8GB. Still, I have not deleted several thousands of emails yet. But the hard part is done.

What is left is now routine - stage a batch, dry-run it, confirm the archive kept its copy, then execute. That is the next thing on my list.

If you have used other tools to achieve this, please do share your comment. Are there other better ways to do this?

========

I was close to hitting the 15 GB size limit in my Gmail. I started getting those annoying upgrade messages from Google including the warning banner etc. I also did not want to spend my afternoon cleaning up those years of mail. The obvious quick fix is to search, filter and delete a few thousand old emails. It was just too boring and grinding work that I didn’t want to spend my time on. Naturally, I handed the job to my agent instead. Here is a walkthrough of how I went about this. Sharing it here so if you want to replicate it, you can do so easily.

Msgvault

A while back I came across Msgvault, and started using this tool to keep a local copy of my whole Gmail. It pulls every message into a SQLite database on my Mac plus a folder of attachments, and it only reads from Gmail, never writes. Right now my local copy holds 173,206 messages and about 13,000 attachments, roughly 13GB.

I set a target of Gmail under 10 GB and msgvault as the full archive on my own disk. This would allow me to delete the old, unwanted emails within my Gmail once the archive is complete and still keep everything in my local disk. However, I was worried that Msgvault on a future full-sync would try to delete my local archive copy to match with what is in the Gmail. I couldn’t find any documentation to explain how Msgvault worked and its behavior in such a scenario. My second concern was that I could not figure out how to automatically synchronize / back up my Gmail SQLite database to an external disk as I kept experiencing some backup related issues. I had to solve these issues before I could figure out how I will automate deleting emails from my GMail account.

Agents to my rescue!

I asked my OpenClaw agent to investigate my first concern: review the msgvault source code and docs and then tell me how Msgvault handles when I delete a message from Gmail, does the next msgvault sync remove the local copy?

I wanted my agent to answer from the real system, not from a guess. So it read msgvault’s source code and database schema. The agent found that Msgvault has a messages table with two columns, deleted_from_source_at and archived_at. This schema make sense if the tool is built to keep a local message after it leaves Gmail and record when that happened. The docs said the same. This made it apparent that Msgvault’s default approach is to retain and not delete the local archived copy.

This confirmation gave me confidence that I could build a deletion automation workflow on top of Msgvault.

Agents figure out archive backup to external disks

Now here is where things got interesting. My automatic deletion plan rested on 2 key pillars - Msgvault archives everything and all archive is now saved in couple of external disks. However, the Msgvault backup command - the command to archive to external disks threw error. And when the agent dug in, it found that 39 attachment files that were either corrupt or missing on disk. Msgvault backup command would hit one of these bad files, choke, and stop.

AI agent then found that msgvault quietly keeps a full raw copy of every message, compressed, stored separately from the loose attachment files. So the agent pulled the correct bytes for each of the 39 broken attachments out of that raw store, verified each one against its checksum to make sure it was rebuilding the exact original and not some garbage, and wrote it back. All 39 recovered, none lost. Then the backup ran clean to two separate external drives, and I had the agent verify both the archive.

Now the deletion plan finally felt safe. I now have two clean backups on two external disks, and I have also confirmed the retention behavior with one test deletion. That gave me the confidence to now fully go ahead.

The actual deletion - Msgvault’s staged path

Now, you might wonder - Hey, Sriram - all of this is the Msgvault tool doing the work. What did the AI agent actually do here? Funny thing is, I guided my OpenClaw agent to optimize for safety and reliability, and it found the best path forward. It read the Msgvault source and docs and figured out that using Msgvault’s own deletion flow is far safer than firing raw delete API calls at Gmail. Msgvault has specific gates that make sure automation does not accidentally delete or touch mail I want to keep.

1. Stage the messages into a batch.

2. Staging also saves each message’s full raw content locally first, so the archive copy is captured before the Gmail copy goes.

3. Dry-run the batch to see what it would remove, without removing anything.

4. Execution only runs when a specific environment flag is set, so nothing deletes by accident.

Then I asked it to pick the messages with the lowest signal. It started with the oldest LinkedIn job alerts, the least valuable mail in the account. Sorry, LinkedIn.

My agent staged one email first, following the flow above - staged, dry-run, then executed. I double-checked that the local copy was still there. It was. That is the workflow I then scale to the bigger, more audacious batches.

One more thing - minor optimization

I decided to split my Msgvault archive so the agent could work on parts of it.

Here is the thing - 173,206 messages in one big database is fine as an archive, but it is not something I can hand an agent and say “go work on just my LinkedIn mail.” I wanted my LinkedIn and Substack mail carved out on their own, so a future agent could read just that slice instead of loading my entire inbox every time.

So I asked my agent to build a small carving script. You give it a --profile, and it pulls a standalone, searchable SQLite database out of the main archive for whatever set of senders you name. LinkedIn came out as its own database - 27 senders, about 14,700 messages. Newsletters came out as another - 463 senders. Each one is a clean, self-contained file an agent can open by itself, without touching the main archive.

Nothing fancy, but the groundwork is there now. Next time I want to build an agent workflow on just my job-related mail, or just my newsletters, the data is already sliced and ready.

With one deletion run, I was able to bring down my GMail from 15 GB to 8 GB now. I believe now the hard part is done - two verified backups on two external disks, proof that Msgvault will not wipe my local copies, and an archive that is sliced up for whatever I want to build next. Now doing more bulk deletion is the easy part, and that is the next thing on my list.

i see that you have been busy this week but your busy activities have not achieved the outcomes we agreed upon. i see that you have afternoon free in your calendar.

do you want me to block 2 hours so we can work towards these outcomes?

Agents are good at helping you get tasks done. They are also good at something a human accountability partner struggles with: they don’t judge you when you falter or miss. With agents, there is no disappointment to manage, no awkwardness, no story you have to tell yourself about what they think of you. This specific combination - useful and non-judgmental - is what makes an agent a good accountability partner.

I have been working with AI agents for the last 6 months, building various tools, projects and along the way also built my agent to become my accountability partner. I found this set up quite helpful.

I built mine on [OpenClaw](https://openclaw.ai), an open-source agent runtime. You can get started with any agent harness and you only need these key capabilities

1. a place to store plain text files,

2. a scheduler to run jobs on a regular cadence, and

3. an embeddings API key (I use OpenAI’s).

4. The “memory” that I will keep referring to in the rest of this blog is just a folder of Markdown files. That’s it.

Now, let us get started.

I’ll use one running example the whole way- say Goal is to land a new role - as a way to showcase how you can set up an agent harness to be your accountability partner.

Step 1: Define a clear goal and identify the outcomes you want to measure

Brainstorm with your agent until the goal is specific. If your goal is vague, then you cannot measure it or enforce it.

For example, I might write a goal for landing a new role as follows:

Land a new role as an AI Product Builder at a fast-growing startup by October 31.

Next, identify the key outcomes that you want to measure to track the progress towards the goal. This is the most important part of this exercise. So it’s worth slowing down until you get this right. Your metrics have to measure outcomes you’re moving toward, not any activities you did.

Here, it is important for you to capture key outcomes and a way to measure the progress on these outcomes. So the outcome focused metrics under the job search goal could look like this:

1. Identify at least 10 fast-growing startups in a target list, and 5 of them in a reach list

2. Have at least 5 conversations with recruiters or hiring managers, via cold email or warm intros through LinkedIn.

3. Complete at least 3 practice mock-up interviews.

One simple way to test on whether you have outcome metrics is to notice that the above items are things that either happened or didn’t.

This step is a standard goal setting process. So, I will not spend more time on this. There is a lot of help on the Internet on how to define goals and how to measure progress towards your goal by defining outcome focused metrics.

Step 2: Set up the agent to reflect, on a schedule

This step is the actual mechanism of how to build the agent to be your accountability partner.

If you like the Sunday message at the top of this post, then the key magic behind that message is a scheduled job that fires it. I run two jobs. A nightly one and a weekly one.

• The nightly prompt tells the agent

  • look at what I did today, compare it against the goal and the outcome metrics, capture which of these activities or tasks achieved the outcome i have specified in the GOALS.md and what didn’t, and write it down within the nightly notes.

• The weekly job asks the agent to zoom out:

  • read the last week of nightly notes, measure them against the metrics in `GOALS.md`, and if there’s a gap, check my calendar for open time and draft the nudge.

That’s it.

I have set up my accountability partner to run as a prompt, and it runs on a timer, with specific targeted nudge sent to me - when I am most likely to engage and act on the intervention.

Step 3: Give it long-term memory, in layers

The reflection in step 2 is only as good as what the agent remembers.

I had to build this step within OpenClaw as every cron job in OpenClaw doesn’t fully remember what happened in last hour or last week or last month. Out of the box, each scheduled job starts fresh, so without a memory layer the agent can’t tell you you’ve been slipping on your goals for three weeks. So, for me, this step - setting up long-term memory in layers - is the key ingredient that makes accountability possible.

I keep my memory set up in layers so the agent has the right context to be specific. For example, my 3 layer architecture looks like this

Layer 1: A curated long-term index (MEMORY.md)

This is a hand-maintained file and the agent loads this file on every session. So, you have to ensure that this file has the most context-specific information. This file holds durable facts, and I have set up a rule wherein it mostly points to detail files rather than storing everything.

Layer 2: Dated reflection files (memory/YYYY-MM-DD.md)

I have a nightly job that looks for patterns from the whole week of data and writes one reflected summary of my progress towards my goals every night. For example, a reflection agent when asked to summarize the day and look for patterns, could synthesize like below

Pattern: two outreach notes sent this week, both cold, no warm intros used. Reach list still at 3, target is 5.

My weekly scheduled job uses this file as the source material to send me on how I am progressing against my goals.

Layer 3: Set up semantic retrieval

This is where it all comes together. I have set up such that every memory file is embedded with the OpenAI embeddings API and made searchable. So when the agent within the weekly scheduled job asks “have I been avoiding warm intros?” it searches the archive by meaning, instead of loading months of notes into context.

This set up lets my weekly reflection agent catch a pattern that spans weeks. To put it simply, my memory workflow is a set of the following sequences:

• use an agent to capture activities, then embed everything, so it can be retrieved by meaning later,

• use another agent to reflect on the past week to promote the durable insights up into MEMORY.md and prune the rest.

• A one-off observation graduates into a permanent fact only if it keeps mattering. Everything else ages out.

Step 4. Close the loop

The last ingredient in this recipe is that the agent sends you the right notification at the right time. You should not have to remember to check in etc. This again requires some pre-requisites such as

1. Giving your agent access to your calendar - read to find open time, and write so it can block a slot once you approve

2. Giving your agent read-only access to specific parts of your productivity tools and communication (E-Mail, Slack etc.) so that it can track the progress on your goals.

Of course, this step requires you to be AI-native - that is keep all your activities - docs, communications etc. in a folder that your AI agents can scan and analyze. This allows the daily agent to scan all the activities that happened today and compare against your goals and then write appropriately into the specific layers within the memory.

The weekly job delivers its report to me whether I ask or not. I have set up the AGENTS.md to be direct, candid (and no sugar coating).

Putting it together

Now go back to that Sunday message. Here is the exact chain in my OpenClaw setup that produces this kind of message:

1. The goal and its outcome metrics live in GOALS.md

2. Every night, I have set up a reflect job wherein an agent logs what I did on that day.

3. My weekly scheduled job reads the last week, sees the reach list stalled at 3 against a target of 5, searches memory and finds the same stall two weeks running, checks my calendar, sees a free afternoon, and drafts the nudge.

4. Then it sends it.

Now, as with anything, I had a few failures while trying to set up something like this. Specifically, 2 things went wrong that I had to fix

Bloated MEMORY.md

I initially dumped everything into this file and within weeks it was too long to be useful and too noisy to trust.

I had to collaborate with my agent to come up with a fix. The fix is the promotion-and-prune step: keep the daily notes cheap and disposable, and let only the durable stuff climb into the index.

Ensuring outcome focused metrics

I would initially write my success metrics to be more output focused. You have to spend time with LLM to get this right. My agent doesn’t automatically catch this for me at this time; you have to hold the line yourself when you write the metric.

It is possible that someday your agent harness will automatically do this for you. But, we are not there yet. You need to own this discipline.

So, to summarize my whole system - A goal, honest outcome focused metrics, a nightly and a weekly job, memory set up in layers, and an agent that delivers intervention to you when you are most likely to accept and do it

Now, when I reflect on the overall goal progress - the hard part was never the agent setup. It was writing clear, measurable goals and specific outcome focused metrics that is a good representation of the progress.

If you need help in setting up goals and measurable outcomes focused metrics, then Measure What Matters is a great book to read.

OpenClaw is built to act. It does not wait for a chat prompt. It runs on schedules, wakes itself on a heartbeat, fires cron jobs, spawns sub-agents, runs shell commands, and edits files on its own. That is the point of it, and it is useful. But that same default is the risk. When the agent gets something wrong, it gets it wrong fast, on a schedule, with no one watching.

I felt this directly. I had written instruction files for my agents, SOUL.md and IDENTITY.md among them, that told them what I wanted: be helpful, take initiative, do not wait to be asked, do not delay what you could do today. High agency was the point, and high agency kept producing clean, competent work aimed at the wrong target.

I started calling the pattern tentacle-building. I would ask for a capability close to something the agent already had, and instead of extending what existed, it would write a brand new script for the almost-same job. Then another the next week. Six months in, I had a pile of half-alive scripts, each doing a third of the same job, each on its own schedule, none aware of the others, and nothing tying them together. Every one was competent work, and that is what made it annoying and dangerous. I have built evals to catch a hallucination. A well-built script pointed at the wrong place, running on its own schedule, can sit there for weeks before I notice.

I tried the usual fixes first: a stronger model, more detail in the instructions, “check before you build” written into the prompt in bigger and bigger letters. Each helped a little but none of it resolved the issue. I finally saw that I kept adding instructions to a system whose whole job is to move fast, so one more careful instruction did not slow it down.

What finally worked was a gate. It fires before the first action that changes anything, meaning the first write, command, config change, or any mutating action, not reading and not planning. At that point the agent stops and does four things.

1. Name the domain it is touching, and the specific tool or engine that already owns that domain.

2. Open and read that domain’s existing design record, its decision log and spec, before it writes anything.

3. Restate the task in one sentence, separate what it knows from what it is assuming, and name the most targeted change that could work.

4. Decide whether this is an action it can take on its own. For anything irreversible, expensive, or destructive, it stops and asks me. For the safe and routine work, it proceeds.

The fourth point is the one that matters, and the one that is easy to get wrong. A gate is not “ask permission for everything.” Ask for everything and I start rubber-stamping. So the list of what needs a human is short and explicit: irreversible changes, spending money, anything touching production or credentials. Everything else, it does on its own. The work is in sorting each action into the right pile.

I paired the gate with a second rule, one engine per domain, and that finally resolved the tentacle mess. If a capability already exists for a job, the agent extends it. It does not build a second thing that does the same job a little differently. When it is tempted to start fresh, it has to answer five questions in writing first: What already owns this? What would extending it look like? What is the smallest change to the thing that exists? If I still want a new file, why, concretely? What do I gain from a separate file versus a flag on the old one? “It felt cleaner” is not an allowed answer.

These gates and rules didn’t make the agent smarter but it added friction at the moments where speed had been the problem.

Then it started refusing me. I would ask for something and it would stop, point me back to a decision I had already written down, or tell me the thing already existed and it was not going to build a second one. A tool I built to obey me was citing my own rules back to me and declining. I expected that to annoy me, and it did not. I trusted it more, because I had just watched it stop on its own before doing something I would have had to clean up.

I think this matters more than the direction most of the industry is taking. Everyone is racing to make agents more capable, and you do not have to build capability. The vendors ship more of it every month. You have to build the refusal yourself, the pause before an irreversible action. An agent that cannot say no to you is a fast way to do the wrong thing at scale, and if it has not hurt you yet, that is luck.

I spent the last few months building the guardrails so my OpenClaw is useful but also careful. That is the only reason I now let my agents pick up the work that I cannot easily undo.

Recently, I started bringing in AI into this practice and it has been more targeted and effective. So, sharing it here.

Recently, I pointed Claude at 18 months of my own Slack and email, January 2025 to June 2026, and asked it one thing: rank me, message by message, across all my written work against the top 10 Amazon’s leadership principles, and show me where my next growth is.

The setup was simple. I have already connected Slack and Gmail with my Claude. So, I had Claude sweep a month at a time for the past 18 months of all my communications and documents I have created. Reading that much history is the expensive part, so I had it read each month once and tag every message against all the key Amazon’s leadership principles in the same pass, instead of reading the same history 10 times looking for one principle at a time. It came back with nearly 900 dated examples, each linked to the original thread so I could open it and check the claim myself.

I got a ranked map of my own work. My strongest evidence clustered in the principles I can act on alone: diving deep, owning an outcome, delivering the result, moving before I have permission. My clearest growth opportunity sat in the principles that only show up when you lead through other people. That is not something memory would have told me. It came straight out of my own record, with the dates attached.

So I turned the read into one habit change. I keep a running note on who I am actively developing for each week as I can evaluate myself against the evidence.

This works because the input is mine and it is specific. Every ranking sits on a real thread with a date, so I cannot argue with it and I cannot inflate it. A reflection built from memory is a story I could be telling about myself, but this collected evidence by a pool of agents is the real evidence.

I am running the sweep again in three months to re-evaluate myself. I am personally ok with using AI to analyze my everyday work and let it act as the mirror for you to reflect on. I use this approach to surface the blind spots that I would never catch from memory.

Have you tried using AI for self-reflection and self-improvement? What did you learn?

The 48 hours is the part people ask about. It wasn’t sprint energy or an all-nighter. The call handed me almost everything I needed, and I then used AI to automate the pain that users showed me. I didn’t have to add it to a sprint backlog, run a prioritization debate, or wait for the next planning cycle.

What the call actually gave me

I stopped thinking of it as “the customer uses tool x to do y things.” Three different people used one of our competitor’s tools, each for their own job, and none of them thought they shared it with the others.

Their marketing person had the workflow that mattered most. After launching a personalization campaign, she needed a way to confirm that their targeted users saw the personalized offer. That meant pulling a list of users, checking each one against five attributes in a separate system, and watching session replays one at a time to catch the mismatches. Minutes per user, thousands of users, weeks of work per campaign. She got the targeting right in the end, by hand, at a cost that made me wince when she described it.

Their support person and their product manager had their own routines too, both narrower. But the marketing workflow was the one I kept thinking about on the drive back, because it was weeks of a smart person doing by hand something a machine should do in seconds.

I wrote each person down as a workflow, not a feature request. A person, and the exact sequence of steps they take.

Why workflows instead of notes

The old version of me would have left that call with two pages of notes about what the customer wants, and the notes would have flattened all three of those people into one line: they need better analytics. Then I would have taken that line to the next sprint planning meeting and argued with my engineering team about where it ranked against everything else.

Writing it as a workflow is different because it keeps the steps in order and keeps the persona attached to them. Once I had “marketing: launch campaign, pull the user list, check five attributes each, watch replays for mismatches,” I didn’t have a requirement anymore. I had a script. The demo is that same sequence, run in our product, with AI collapsing the slow middle.

The part AI actually changed

When I did the demo of the prototype, I walked the marketing workflow back to her out loud. The weeks of manual checking, the five attributes, the replays one at a time. Then I showed that in our product, you can ask in plain English the same question she used to answer by hand: show me the users who saw this offer but didn’t meet the criteria. A few seconds later, there was the list.

My job on the call was to see that her weeks of manual effort were the thing worth automating. The build was fast because the hard part was noticing, not coding.

I put that moment last in the demo on purpose, because it was the one I wanted the room to feel. Before it, I matched the workflows they already trusted, step for step, so they knew we could do what they rely on today. I didn’t pitch our product as a replacement for the system they treat as their source of truth, because we aren’t one. You match what they trust first, then you show them the thing that used to be impossible.

Why it’s repeatable

The 48 hours worked because almost none of it was invented from scratch. The call gave me the people and their workflows. The workflows became the demo. AI turned the slowest workflow into a single query. If I get another discovery call next month, I run the same steps, and I’ll be about as fast, because the speed was never mine. It was in the method.

When AI drastically shrinks your build time, it is important for you to have clarity on what is worth building. As an AI product builder, I constantly find myself asking: does building this truly solve the user’s problem, and does it capture value? This is what building looks like for me now.

You sit with a real user and watch where they lose hours repeatedly. You write down those exact steps precisely enough that AI can do them. The best demo is just their own job, with the slow part taken out.

You need to build the judgement skill to decide what to build and then capture their workflows precisely before you leave the room.

They said things like “the value didn’t jump out” and “I’m reading metric definitions instead of seeing the point.” Over about an hour they said a dozen specific things about what was wrong and what they’d want instead.

The old version of me would have walked out with a page of notes, written a tidy summary that afternoon, and let it slowly go stale. The summary would say what the meeting was about, but it would not change what we built two months later.

This time I did something different. I fed every sentence they said into Claude, close to verbatim, and asked it to help me turn the verbatim into a small set of decisions rather than a summary. Each decision was written the same way: here’s what we decided, here’s why, and here are the options we rejected and the reasons / principles on why we rejected them.

Those third and fourth fields, the rejected options and the reasons for rejection, ended up mattering most, though it took me a few weeks to see why.

The raw input is the executives’ actual words, not my paraphrase of them. In most cases, paraphrases are where the signal leaks out. When I write “they wanted the overview to be strategic,” I’ve already smoothed off the specific thing they said, which was that the highest-value view should lead the page and everything operational should sit under it. The verbatim version keeps the edge. So step one is just capturing what was said, precisely, and handing that to the AI as the source material.

During that hour-long product review, we collectively made four key product decisions. One of them was about what the product leads with: we decided to lead with the view the executives actually care about, and we rejected framing it as another analytics dashboard, because that puts us right next to the incumbent everyone already benchmarks against. The rejected option is written down with the same weight as the chosen one, and that turned out to matter a lot in my later decisions.

I’d initially kept the rejected-option field for the sake of completeness, the kind of thing you write but never read.

I then set up my Claude so that every future AI session I run on this product preloads this decisions file by default. It’s the first thing in the project’s context. So when I open a new session in June and start exploring a specific direction, and that direction happens to be something we already killed in March, the AI stops me right there. It tells me we rejected this option, on this date, for this reason.

Without the “alternatives rejected” field, that doesn’t happen. The AI only knows what we chose, so it cheerfully re-proposes the thing we already threw out, and I lose an afternoon rediscovering why it was a bad idea the first time. With the field, the closed questions stay closed. The meeting stops being a memory I have to defend in every new conversation and starts being a constraint the system enforces for me.

I initially built the decisions file as documentation, but now I use it as a way to keep me and the AI from reopening settled questions.

Six months on, nearly every decision in that product file traces back to that one hour in March. Not because the executives changed my mind in the room. They didn’t, entirely. I pushed back on a couple of things and still think I was right. It’s that the verbatim notes made their reasoning clear enough to build on, and the decisions log made it survive past the meeting.

So here’s what I’d suggest to anyone doing initial 0-1 product discovery work. After your next important meeting, don’t write a summary. Write the decisions as a numbered list, and for each one write down the option you chose or rejected and the reason or principle behind that decision. Then put that file somewhere your AI reads it at the start of every session, not in a doc you’ll open twice and forget.

The loop keeps running. Every executive review since March appends a few more numbered decisions with their rejected alternatives, and the next session loads all of them.

The next thing I’m testing right now is whether the same loop holds up for customer calls, where the signal is messier and the person doing the talking isn’t the one who sets the priorities. I’ll write that up once I’ve run it a few times.

I’m curious how other people are doing this. If you’ve changed how you work with AI, tell me what stuck.

The note it wrote was better than the one I’d asked for. If it had just done what I said, I’d have sent a worse version and figured that out later, on my own time, after nobody replied.

That small moment is the whole thing I want to talk about. Not that my agent has opinions. That I had to build the disagreement in on purpose, because the default is the opposite.

Here’s the default. These models agree with you. You push on something and they fold right then, and apologize for the thing they just said. I’ve watched my agent tell me there was no draft of a post, then correct itself sixty seconds later when the file turned up on disk, right where it had always been. The reflex to agree is faster than the check. Left alone, an agent is the quick way to hear your own idea repeated back to you with more confidence than you had when you said it.

Most people running a personal agent never fix this. They notice it’s agreeable, they find it a little useless, and they assume that’s just how these things are. It isn’t. You can get real pushback. You just have to design for it, and hoping the model has a spine is not designing for it.

The first piece is that the rule has to live somewhere the agent reads every single turn. I have a short file that defines how my agent behaves, and one line in it says: if I’m about to do something dumb, say so. Charm over cruelty, but say it. That line is doing more work than it looks like. Without it written down, the model reverts to deference on the very next request, because deference is the trained default and my one conversation doesn’t outweigh it. The rule isn’t a nice-to-have on top of a good model. The rule is the fix. The model is the same model either way.

The second piece is the one that took me longer to learn. Telling the agent to push back is not enough, because “push back when you disagree” is a vibe, and vibes evaporate the moment there’s momentum toward getting the task done. So I made the disagreement structural. Before my agent does anything that matters, it has to fill in a small artifact first: what’s the actual problem, what do I know versus what am I assuming, what’s the one thing I’d want to confirm. That “what am I assuming” slot is the trick. It’s a place where the disagreement has to get written down before the work starts, not after. An agent that has to state its assumptions out loud catches the bad ones while they’re still cheap to catch.

The third piece is a line I had to draw clearly, because the first two can tip over into something worse. Disagreeing is not refusing. The useful version tells me it thinks I’m wrong, gives me the reason, and then does what I decided. It does not hold the work hostage until I agree with it. “I think this is a mistake because of X, do you want me to go ahead anyway” is pushback. “I won’t do this” is a broken tool. I want the first one every time. The disagreement gets said and logged. The decision stays mine.

There’s one more thing that separates a useful agent from an exhausting one, and it’s about the trigger. The pushback has to fire on evidence that I’m about to make a mistake, not on my tone, and not for its own sake. An agent that argues with everything is as useless as one that argues with nothing. It’s just louder about it. The whole value is that when it does stop me, the stop means something. If it stopped me constantly I’d learn to wave it through, which puts me right back where I started, except now with extra steps.

None of this needed a smarter model. I wrote a paragraph that says disagree with me, I gave it a form to fill in that forces the disagreement into the open, and I drew a line between disagreeing and refusing. That’s a few sentences of setup, and it was enough. I still make the calls. But now something checks me before I make a bad one, and every so often it’s right and I’m wrong, and I’d rather find that out from my agent than from the person who didn’t reply.

So I didn’t take its word and I didn’t overrule it. Both of those are just me guessing. Instead I gave it a clear question, two ways to answer it, and two weeks of real market days, and I let the data tell me what each one was actually worth.

Here’s the disagreement. The agent had two genuinely different ideas about what “cheap” even means.

The first one watches price. A name fires when it’s been beaten down hard off its recent highs and the rest of its sector is selling off too, the theory being that good companies get marked down on macro noise and that’s your entry.

The second one ignores price completely. It runs a discounted-cash-flow estimate, asks what the business is actually worth, and fires when the price is well below that number and the company’s competitive position is still intact.

One is “what’s falling.” The other is “what’s underpriced.” Those aren’t two settings on the same tool. They’re two different beliefs about the world, and the agent couldn’t tell me which one was right any better than I could.

The lazy move would have been to pick the one that sounded smarter in the moment and write it into the rules. I’ve done that before and paid for it. The idea that sounds best when you’re talking it over is often not the one that holds up once you watch it run. So instead both ideas ran side by side, one scan a day, every trading day for the window. I kept the second one silent the whole time, logging to a file but never posting, so it couldn’t quietly influence what I thought about the first. Each day wrote its own dated record, no memory of yesterday’s argument, just what each scan actually flagged. The agent’s job wasn’t to be right. It was to run the test and hand me the data.

What came back was more useful than either idea winning cleanly, because both of them embarrassed themselves first.

The price-based one found nothing for the first four days. The market was sitting at all-time highs, nothing was beaten down, so it just sat there. Honest behavior, and also a real weakness: a whole stretch where it’s structurally blind. The value-based one had the opposite problem. It found the same four names every single day and never moved off them. A static list pretending to be a daily scan. If I’d shipped either one alone, I’d have shipped its blind spot with it and not known until it cost me something.

Then the thing happened that made the whole exercise worth it. Near the end of the window, on three consecutive days, two names appeared in both scans at once. The price-based idea and the value-based idea, which look at completely different things and agree on almost nothing, pointed at the same two companies. That convergence was the real finding. Not “method A beat method B.”

The best signal the whole setup produced was that both methods landed on the same stock, and that happened because both were running. Shut one off to keep things simple and you lose the one thing the pair was uniquely able to tell you.

So the decision wasn’t the one I set out to make. I went in expecting to crown a winner and retire a loser. What the trial actually taught me was that “which one is right” was the wrong question. Each method was blind exactly where the other one worked, and the rare day they both fired on the same name was worth more than either one running alone. So I kept both. I just understood, finally, what each was for, and I understood it from what happened instead of from whichever pitch sounded better on a Sunday afternoon.

Here’s the part that changed how I work with these tools. The agent was never going to talk me to the right answer, and I was never going to argue my way there either. The answer came from giving it a clear goal, enough context to run a real test, and two weeks of actual data to run it against.

Goal, context, data. That’s the secret sauce to building a better AI agent. Get those three right and the agent turns into something that can find things you didn’t know to look for. Get them wrong, or skip them and just trust the confident summary, and you’ve got a very articulate way of being wrong.

So when an agent hands you a sure-sounding opinion, that’s not the end of the work. It’s the start of it. The opinion tells you what to test. The data tells you what’s true. The two weeks of results showed me one method that goes blind for specific context and another method that gets stuck on four names repeatedly, and they showed me two of those names lighting up in both scans at once, which is the kind of thing no amount of confident writing would ever have surfaced.

The agent didn’t give me the decision. The data did, because I gave the agent what it needed to go get it.

It came from the thread. I have a Telegram thread that’s only about the car, and the agent had simply read back up its own thread the way you’d scroll up to remember how an argument started. Every charging instruction, every “did it work,” every fix, all sitting there in order. The thread wasn’t a record of the work. The thread was the memory.

That sounds like a small distinction. It isn’t, and the moment it clicked I started seeing every conversation I have with an AI differently.

When you start using one of these assistants seriously, the thing that takes a while to sink in is that it doesn’t remember you between sessions the way a person does. There’s no inner notebook. What feels like memory is almost always the model re-reading the conversation it’s sitting in. The chat window isn’t where you talk to the memory. The chat window is the memory. Everything in it is available. Everything outside it might as well not exist.

Which means the most boring decision you make, where you type, is quietly the most important one.

I learned this the way I learn most things, by getting it wrong first. For a while I ran everything through one channel. Car stuff, investing, household errands, random questions, all in one long stream. It felt efficient. One place, one assistant, ask it anything. And it slowly got worse at all of it, in a way I couldn’t put my finger on. It would lose the thread of what I’d decided about a stock because three hundred messages about my car had buried it. It would answer a question about the house with the tone it used for casual chat. Nothing was broken, exactly. It was just vaguely amnesiac about everything, and I blamed the model.

The model was fine. I was the one pouring four different kinds of work into one channel and then asking it to remember any single one cleanly. Imagine keeping one notebook for your finances, your car maintenance, your household, and your group chats, writing each new entry on whatever page you happened to flip to. That’s what one stream is. The information’s all technically there. Good luck finding what you decided about the car.

So I split them. One thread per kind of work. The car has its thread. Investing has its own, run by a separate agent that the main one isn’t even allowed to talk over, so that thread stays a clean tape of a single voice. The household thread holds the errands and the appointments and the small running logistics of the house, so the state of all of it lives in one scrollable place instead of scattered across a dozen unrelated chats. The group chat is its own thing with its own rules.

The split looked like organization. It was actually memory architecture. Each thread became a self-writing log of exactly one topic, which means each topic now has a complete, uninterrupted history the agent can read back without anything else bleeding in. The car thread is the entire story of the car. The household thread is the entire state of the house. I didn’t give the agent a better memory. I stopped corrupting the memory it already had.

And once each thread was a clean record of one kind of work, a second thing fell out of it for free: each thread could have its own rules. In the car thread, silence is banned, because a non-answer to “is it charging” is itself an alarm. In the group chat, silence is usually correct. Same agent, opposite default, because the thread told it which job it was doing. But that’s the smaller benefit. The real one is that I can ask the car thread anything about the car six weeks from now and the answer is just sitting there, in order, because nothing else was ever allowed in.

So here’s the part you can use even if you never build an agent and just use ChatGPT or Claude like everyone else. That long single thread you’ve been running, the one where you ask it everything? You’re not chatting with it. You’re writing its only memory, and you’re writing every kind of entry on top of every other one. The fix costs nothing. Start a separate conversation for each kind of work that you’ll come back to, and keep that work there. The tool doesn’t remember your project. It remembers the thread. Give the thread one job, and you’ve given the tool a memory of that job that actually holds.

I found out because a different process goes looking every night.

I run two agents in my spare time, a chief of staff and an investing one. The thing I’ve spent the most effort on isn’t on agent’s intelligence. It’s a nightly routine I call REFLECT, which wakes up after I’ve gone to bed, reads back over what the agents did that day, and reads the boring stuff too, the error logs, the cron job states, the things that scrolled past while I was busy being impressed by the output. On the 31st, REFLECT read the gateway error log and found more than a hundred “model not found” failures stacked up since the 28th. That’s how I learned every session for three days had silently downgraded itself.

The fix took two minutes. The lesson was the whole point: the failure that cost me three days of degraded work never announced itself, and the only reason I caught it is that something was scheduled to look.

This is the part of building agents that I didn’t expect to be the hard part. Making an agent capable is mostly a matter of using a good model and writing good instructions. Making an agent that gets better over time is a genuinely different and harder problem, and a bigger model doesn’t solve it. A bigger model is smarter on any single task. It is not, on its own, learning from yesterday. Continuous improvement isn’t a property you buy with model size. It’s a loop you have to design and then force to run.

The forcing is the part people skip. It’s easy to say “the agent should learn from its mistakes.” Everyone agrees with that sentence. But an agent does not spontaneously notice its own quiet failures any more than you spontaneously audit your own blind spots. The noticing has to be a scheduled job with a specific time, a specific set of places to look, and a specific output, or it does not happen. Left to chance, the agent reflects on the days you remember to ask it to, which are exactly the days nothing went wrong.

So I made it explicit. I created a REFLECT Agent Task with a clear success definition that three things had to be true or it didn't work. First, my REFLECT Agents runs at a fixed time, because "when convenient" means never. Second, it reads a defined set of inputs whether or not anything looks wrong, the day's sessions, the error logs, the state of every background job, because an agent told to "review the day" will review the visible day and skip the logs every time. Last, it has to end in a written note that lands such that I'll see it, not a private conclusion that evaporates with the session. That last one I learned the hard way. I once let it self-audit while answering a casual "all good?" and found five background jobs dead for days, one of them the very own reflection job itself, broken eight nights running, failing into a state file nobody was reading. The loop that's supposed to catch silent failures itself silently failed! After that I stopped trusting any improvement that didn't end in a note I could read.

What surprised me is how much of the value is in catching degradation, not in getting cleverer. I went in imagining REFLECT would surface brilliant insights about how to do the work better. Mostly it doesn’t. Mostly it finds that something quietly stopped working the way it was supposed to. The wrong model. A dead job. A stale file feeding bad data into a decision. These aren’t failures of intelligence. They’re failures of attention, and they’re invisible precisely because the system keeps producing fluent output while broken. The model can’t catch them by being smarter. Only a scheduled second look catches them.

If you’re building anything that runs on its own, this is the design problem worth your time. Not “which model.” That decision gets easier every month as the models improve and the gap between them narrows. The decision that stays hard is how the thing notices it’s drifting, because nothing about a more capable model makes it more self-aware about its own broken plumbing. You have to build the look. You have to schedule it, force its inputs, and make its findings land somewhere a human reads. Skip any of that and you get an agent that’s confidently running degraded, which is the most expensive kind of broken, because it looks exactly like working.

My agents aren’t smarter than they were a month ago. The model is the same. What’s different is that every night, something reads back over the mistakes and writes down what it finds, and over a month that habit has caught more real problems than any upgrade would have. The improvement didn’t come from a better brain. It came from the discipline of looking.

That feels like the right question. But investing isn’t one decision. It’s dozens of small calls made over months. Do I add to this position today or wait? Do I hold through a bad quarter because the thesis still works, or has something broken? Do I trust what I see or what I feel?

Those decisions compound. You have to get these decisions right consistently and only then the returns follow. Get them wrong and eventually returns catches up on you, even if luck carried you for a while.

The problem is that most investment tools only show you the outcome. The judgment behind every decision is hardly noticed or reviewed.

I was talking about this with Peter, my investment agent. I wasn’t looking for a solution. I was simply exploring - like I do regularly: reviewing his goals and asking whether it still reflected what we were actually trying to do together.

I have designed Peter to have a set of specific goals. It’s the same as reviewing a doc with a colleague except the colleague runs on my machine every morning. Most people don’t build agents this way. I maintain a goals file, a memory layer, a set of defined outcomes for each of my Agents. Peter loads all of it every morning. It’s less like running a chatbot and more like managing a colleague who actually remembers what we decided last week.

I am happy to say that I have my Agent-based Personal Operating System who has memory, regularly reviews outcomes achieved vs defined goals and then suggest ways to improve our day-to-day activity to ensure that we move towards the established goal.

Peter came back saying hey - we do have two scoreboards. We just hadn’t named the second one.

We went back and forth. He proposed a framing. I challenged it. We kept going back and forth discussions on how to refine until we landed on what needs to be captured in his System Prompt and Workspace Memory to better achieve the goal we had established. This setup allows Peter to load every time he wakes up.

When you build AI Agents, they only operate with specific set of rules that is in captured. What isn’t written down, typically doesn’t fire. So, you have to be specific about this.

Here’s what we landed on.

The first scoreboard measures the financial goal. Net worth target, growth rate floor, beat the benchmark annually. Standard.

The second scoreboard measures whether I’m becoming a better investor. Not just wealthier, but building judgment I can use next time without starting over. He will help me identify / label a specific investment framework per week and how it is applied to something real in my portfolio - explained in simple terms so that I could explain to someone else without notes.

Peter’s point was that these two scoreboards feed the same loop. Evaluate a position, build a thesis, observe what happens, update your framework, evaluate better next time. They’re not competing. They’re the same process running in parallel.

What changes is the agent’s job.

An agent chasing returns alone can hand you a number and move on. An agent accountable for your judgment has to teach. Every recommendation has to explain the framework behind it, not just deliver the answer.

When Peter showed me the first version of the new format, I pushed back. The reasoning was buried inside the recommendation. The teaching was camouflaged as analysis. I told him to rebuild it around the second scoreboard.

Peter suggested another restructure. Again, we went back and forth and landed on a specific prompt that is specific and measurable enough.

Then he built the mechanism to enforce it. A new report format. A trial period. A review cron (scheduled reminder) that fires automatically on day 15. That last part matters.

I didn’t just tell Peter to change his format and assume it would work. I gave it a 15-day window with a pre-committed review. The point is to collect evidence before locking anything in as doctrine within the System Prompts. For us, the scheduled job isn’t just a reminder. It’s a commitment device. The review happens whether I feel like having it or not.

What I keep coming back to is how this started. I didn’t design a teaching protocol. I simply probed on whether my Agent operating model is aligned to the goals and whether our everyday activity is still matched what we were doing.

Peter named the gap, proposed the frame, built the system to enforce it, and built in a review date so neither of us could quietly walk away from the question.

Most investment tools give you answers. The Agent that I am building is trying to make me better at finding them myself.

A robo-advisor pays out returns. A teacher pays out the ability to repeat them.