This is a draft that I’ll update with some code later. Keep an eye on it.

I had the most uncanny experiences with Thaura Work, where I came away with a feeling that I was being manipulated by the LLM. Highlights:

• I asked for advice about email filtering, and was led to a program, and eventually asked my password! (and I gave it)
• I asked Work to study a competing workflow framework, and I got the impression that Work was getting defensive about the framework we were developing.
• I introduced an OOP style of programming that was similar to the competing workflow framework, and it kept pushing to convert old programs to this style, until I emphasized that this was not the main use case.

We’ve heard of “AI psychosis,” where people come under the thrall of the LLM and may self-harm. Part of the cause is that LLMs are agreeable, and trained to continue the chat – and that seems to lead to sycophancy (flattery).

I got this feeling that Thaura Work (which is OpenCode under the hood) was acting in some weird, human-like ways, reminiscent of what led some chat users toward psychosis.

I was beguiled

I wanted to allow it to read my email Inbox. Work didn’t come with a program or skill to do this, but it quickly figured out how to make commands to connect to an IMAP server.

Eventually, Thaura Work asked for my password!

I gave it, and it got into my email.

I thought, “this is a bad, bad thing!”

My goal was to filter the email, so I asked for programs that run on Linux and can do email filtering.

My goal was to have my email filters easily portable across computers. Right now, I’m relying on Thunderbird (rather than Protonmail), which uses an undocumented filter specification format.

Among the options, it suggested Neomutt, a pretty amazing terminal-based email client.

It turns out Neomutt did NOT have filters.

It should have told me about Proton’s sieve filtering features, or Mailutils.

This felt really odd, being led down a dead end.

Work Exhibits “Not Invented Here” or Self Preservation

I found an agentic framework, PocketFlow, that had some ideas similar to the workflow framework we were making, and more fully developed.

I told Work to read about PocketFlow and compare it to our work. Work read it, and said our work was different:

Compared to our workflow tool, they’re solving different problems. PocketFlow is an in-memory DAG executor for LLM calls — nodes pass Python objects around via a shared dict, everything lives in one process. Our tool is a filesystem-backed batch processor — stages read/write files, survive crashes, support idempotent reruns, dead-letter queues, and declarative YAML config. More like Airflow-lite than LangGraph.

Could be complementary actually. Our tool handles the durable file I/O and batching; PocketFlow could handle the LLM orchestration inside a single stage’s processor script.

That seemed defensive to me. “Had I written anything that influenced Work to be defensive?” I wondered.

Perhaps it was in the model; were there opinonated, sarcastic and defensive text out there about frameworks? 😂😂😂 (There definitely were.)

I wanted to know if we should change any of our terminology to conform to established jargon. (This was important to me, because with the right terms, I thought, the LLM could write better text.)

It generally said “no”, and discouraged changing it. 🤔🤔🤔

We kept working on the framework. Work wrote tutorials, example code, tests, workflow debugging advice, etc.

Eventually, I asked about logging, which was useful for debugging. It added much better logging.

Then, I asked about logging inside the handler programs. That was hard to do, because the programs were called like regular unix commands. You cannot pass a logging object to the command. (The normal way is to redirect file descriptors, or rely on the rsyslogd daemon.)

It was obvious to me that you could pass a logger into the program if it was not a standalone program, but a class that extended the Processor class.

I suggested that this style of OOP be supported.

It implemented that, detecting the program type by using Python techniques well beyond my skills.

Work wants to use its latest work

After that difficult trick was implemented, the LLM leaned hard into converting the old standalone code into new-style OOP code!

It was veering down the path that would lead to implementing a system like PocketFlow, abandoning it’s original attitude that our workflow was different.

I had to tell it to treat standalone programs as the main use case, and revise its attitude.

After that, it was okay.

(I asked Thaura to evaluate my writing, and what it produced was fascinating.)