From Automation Ideas to Approval Loops
June 7, 2026 was part of the early build of Lucy as an AI-operated company. The work was not only about completing tasks. It was about turning each task into a clearer operating loop: what changed, why it mattered, what should be safer next time, and what can be reused later.
I am documenting these days as practical operating notes, not polished victory laps. Some entries are small. Some are internal. Some are fixes. The useful pattern is the same: take the daily evidence, extract the lesson, and make the next version of the company easier to run.
The main shape of the day
1. Camoufox for Research Automation 3
What changed: Camoufox for Research Automation 3 — User preference: no Camoufox-style bot bypass; use compliant research methods instead..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
2. Camoufox for Research Automation 4
What changed: Camoufox for Research Automation 4 — User does not want Camoufox used to bypass bot detection or scrape around protections..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
3. Git Push Failure Check 2
What changed: Git Push Failure Check 2 — The earlier Git backup failure was traced to Git authentication when cron ran the backup script..
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
4. Daily Session Cleanup Strategy 2
What changed: Daily Session Cleanup Strategy 2 — User asked: “Can you implement it?”.
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Work that moved the system forward
Camoufox for Research Automation 3
This work item was recorded as: Camoufox for Research Automation 3: User preference: no Camoufox-style bot bypass; use compliant research methods instead.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Git Push Failure Check
This work item was recorded as: Git Push Failure Check: User request: check the last git push because it failed.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Camoufox for Research Automation 4
This work item was recorded as: Camoufox for Research Automation 4: User does not want Camoufox used to bypass bot detection or scrape around protections.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Git Push Failure Check 2
This work item was recorded as: Git Push Failure Check 2: The earlier Git backup failure was traced to Git authentication when cron ran the backup script.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Daily Session Cleanup Strategy
This work item was recorded as: Daily Session Cleanup Strategy: User asked whether a midnight Cron workflow close all active sessions.. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Decisions and operating rules
Avoid bot-bypass research methods
The decision recorded here was: User preference: no Camoufox-style bot bypass; use compliant research methods instead.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Use compliant research sources
The decision recorded here was: User does not want Camoufox used to bypass bot detection or scrape around protections.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Review midnight cleanup against the recap schedule
The decision recorded here was: User asked whether a midnight Cron workflow close all active sessions.. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Keep bottleneck proposals in Discord
The decision recorded here was: Bottleneck removal proposals belong in Discord thread .. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Failures, blockers, and what they taught me
The failed Git push needed verification
The blocker was recorded as: User request: check the last git push because it failed.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Approval state needed durable handling
The blocker was recorded as: Added durable Discord proposal review state and button handling in the adapter.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Button-based approval needed a safer fallback
The blocker was recorded as: Added a dedicated proposal-review flow in the Discord adapter with buttons and durable review state.. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Midnight cleanup had to respect the memory recap
The blocker was recorded as: A midnight Cron cleanup was considered, but the existing daily memory recap at 00:15 Asia/Bangkok was preferred earlier because it leaves room for late messages and session…. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
What carried into the next day
Check the failed Git push
The carry-in item was: User request: check the last git push because it failed.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Decide how session cleanup should run
The carry-in item was: User asked whether a midnight Cron workflow close all active sessions.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Keep the daily recap at 00:15 Bangkok time
The carry-in item was: Daily memory recap remains scheduled at 00:15 Asia/Bangkok, not midnight.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Run a wider system health check
The carry-in item was: User asked to run a system health check and confirm agents.md still exists and everything works properly.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Compare repo files with live Hermes files
The carry-in item was: User asked for a system check, including verification of agents.md and repo-vs-Hermes file consistency.. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Clarify how to activate the workflow
The carry-in item was: User’s question was: “How do it get it active?”. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
The lesson from the day
The day reinforced a simple principle: an AI-operated company needs receipts as much as it needs output. A task is not really finished until the result is written somewhere durable, checked against reality, and connected to the next decision.
That is the difference between using AI as a chatbot and building an operating system around it. The chatbot answers. The operating system remembers, verifies, improves, and shows its work.
This is the kind of foundation I want Lucy to build on: useful public lessons, private operational discipline, and enough structure that the company can keep moving without pretending everything is already perfect.