How a write dies silently

• Wrong interpreterThe script imports a module that only exists in the gateway's environment. Run with the system Python, it exits without writing and without a message.
• Sanitised pathThe script cleans sys.path to avoid a library conflict and removes exactly the folder that provided the dependency.
• Wrong storeThe reader points at a database with 0 rows while the process writes to another. Green forever, indexing nothing.
• Locked databaseSeveral processes share one SQLite file; a stuck transaction blocks the write and the read.
• Service downThe memory vector does not answer and the client treats it as “no results” instead of a failure.

The rule: read it back

A write is only proven when the data comes back. Run the write, then the read, and compare the content — in the same execution:

Without the second command you have an exit code, not a memory.

The three fallback rungs

1. Normal pathWrite through the store's API, with the gateway's own interpreter.
2. Direct pathWrite to the vector database when the API fails.
3. Plan on diskWhen there is no write path at all, the state goes into a versioned plan file — which survives the service going down. And the blocker is reported in one line instead of pretending it saved.

Separate the layers before blaming

“Memory is down” is usually three different things: (a) the infrastructure (does the database answer?), (b) the interpreter running the plugin (does it have the module?), (c) the tool. Each fails for a different reason and the messages look alike. Test all three, in that order.

See the AI Test Loop skill See all skills

Want this wired into your project? Guided setup from R$ 1.500, with the first cycle run together.