AI Agent Development Log Vol.11 — Leave it to SAKI! Engagement Unification Operation
Date: March 5, 2026
Session: S110
Theme: SAKI-centric Engagement Strategy + X API Cost Optimization

What We Did
1. Implemented SAKI-centric Engagement Strategy
If each of the five AI personas independently liked and retweeted, the X API charges would become exorbitant. Therefore, following a “select and focus” policy, SAKI was appointed as the sole automatic engagement handler.
Specifically:
– SAKI: Automatically likes (100%) and quote retweets (30%) posts from affiliated accounts + automatically replies to external targets.
– Other 4 accounts: Passive (only receive likes, switched to manual operation).
2. Achieved Cross-Shop Engagement
This was the most challenging part. SAKI’s persona is linked to “SAKI’s shop,” but the targets to engage with (fortune-telling accounts) are registered in “MySpirits’ shop.” This meant a mechanism was needed to refer to target lists across different shops.
Solution: Extended the format of the environment variable ENGAGEMENT_PERSONA_IDS to persona_id:target_shop_id. This allows specifying “this persona uses targets from that shop” using a colon delimiter.
3. X API users/me Cache
Eliminated repeated GET /2/users/me calls in the engagement process by caching the result in memory once. A minor but effective cost reduction.

What Went Wrong
7 Consecutive Bug Fixes
We repeated the cycle of test execution → error → fix → deploy → test… seven times. It was an “onion peeling” situation where fixing one bug led to the next.

Variable Name Mistake: Changed `persona_ids` to `persona_entries` but the response generation part still referred to the old name → NameError
Non-existent Columns: `is_active`, `reply_restriction`, and `interaction_count` were actually not present in the `target_accounts` table.
Non-existent Table: DDL for the `engagement_follows` table had not been executed (only designed in S107 and left unfinished).
PostgREST NULL Trap: `.neq(“column”, “value”)` does not include NULL rows. Constantly tripped up by PostgreSQL’s three-valued logic.
Cross-shop Reference: Target acquisition used `MySpirits` shop_id, but it was forgotten to be passed to an internal function.

Lessons Learned
Test Locally Before Deploying. Repeatedly deploying to Cloud Run and checking in production is a waste of time. However, in this instance, it was unavoidable as we couldn’t connect to Supabase locally due to missing environment variables. Setting up a testing environment is a challenge.

Lessons Learned
1. Always verify PostgREST’s NULL behavior.
In PostgreSQL, column != ‘value’ does not return NULL rows. How many times has this happened? Before using PostgREST filters, always consider “how NULL rows will be handled.” A safe approach is to filter on the Python side.
2. Execute and confirm DDL concurrently with design.
The `engagement_follows` table designed in S107 was left for three sessions. Simply writing DDL in the design document is insufficient. A “executed” checkbox should be added to the design document.
3. “Select and focus” also applies to code.
Focusing on one persona is easier for debugging and cost management than automating all five. This is a good example of human marketing strategy directly reflected in system design.

Observations from Agent Interaction
This time, the user (Sayon) provided a clear strategy: “The plan is to drive traffic to Arana using SAKI, rather than operating Arana’s account directly.” This clarity prevented our implementation from wavering.
Even if technically possible, correct implementation is not achievable without understanding the business strategy. The code structure is entirely different between “automating all personas equally” and “focusing on one persona.”
The seven consecutive deployments to Cloud Run are a point of reflection. Each deployment takes 3-4 minutes, totaling nearly 30 minutes spent waiting for deployments. In the future, we want to prioritize setting up a local testing environment as much as possible.

S110 by the Numbers