ChatGPT Limitation: No Reusable Addressable Working Memory Between Action Calls

Practical Problem

While working on the ChatGPT ↔ fi1osof.ru integration, we encountered a distinct class of limitations: ChatGPT can generate a large intermediate result and execute a sequence of API calls, but it lacks a convenient mechanism to save this result as an independent addressable object and then reference it in subsequent actions.

This problem manifested when writing a large worklog to a task. The worklog text was already generated in the dialogue, but every time createTaskWorkLog was called, the entire text had to be embedded into the GraphQL variables again.

When the first write attempt failed with a resolver error, the retry required sending the exact same long Markdown all over again.

Essentially, there is a missing intermediate layer of the following type:

generate content
→ save as var/draft/artifact
→ get ID
→ use ID in subsequent API operations

Current Tools and Why They Are Insufficient

GraphQL variables

GraphQL variables are only suitable for parameterizing a single HTTP request.

They do not persist between calls and do not allow referencing the result of a previous step.

Current dialogue history

The model sees the previously generated text in context, but the chat history is not an addressable programmatic object.

You cannot reliably pass something like this to an Action:

content = the Markdown that was generated a few messages ago

At the HTTP/GraphQL level, the actual content value is still required, so it is re-serialized and sent in full.

fi1osof.ru Domain Entities

Technically, one could temporarily save the text as a Task, File, Fact, or another persistent entity, but this is incorrect semantics and pollutes the domain model with intermediate runtime data.

The problem requires a universal working memory independent of a specific business entity.

Why This Is Bad

1. Resending Large Payloads

Long texts, JSONs, analysis results, and other objects have to be passed through Actions over and over again.

This increases request sizes and makes the integration more fragile.

2. No Proper Multi-Step Workflow

It is impossible to naturally divide the work into stages:

generate
→ save
→ verify
→ use
→ reuse

Instead, the generation and use of the intermediate result are effectively chained through the current chat context.

3. Poor Error Resilience

If the final mutation fails, the original payload has to be transmitted again.

You cannot simply retry the operation using the ID of an already saved artifact.

4. The Problem Is Not Limited to Worklogs

The exact same issue will arise for:

• long task descriptions;
• reports;
• Markdown documents;
• JSON configurations;
• research results;
• ID lists;
• GraphQL query results;
• prepared payloads;
• data that needs to be passed to another agent.

5. It Limits Agentic Workflows

In our architecture, ChatGPT is used as an external reasoning runtime. For proper agentic operation, it needs not only long-term knowledge memory, but also an operational addressable workspace state between individual actions.

Without this, the external agent can think and call APIs, but its intermediate working results remain tied to the text context of the dialogue instead of a proper runtime state.

Desired Abstraction

What we need is not necessarily a "file" or a specialized TaskWorkLogDraft, but a universal addressable value/artifact/variable.

Conceptually:

var_abc123 = "# Large Markdown..."

After which one can execute:

createTaskWorkLog(
  taskId: "...",
  content: var_abc123
)

or use the same object in another operation.

Such a mechanism turns into an intermediate working memory between the external AI client and fi1osof.ru/haih-agent.

Related Task for haih-agent Improvement

A detailed problem statement has been moved to a separate haih-agent project task:

tasks/cmt839tuu000kmq0q72h9ppm9

"Add addressable reusable working memory for external AI clients".

It describes requirements for universal variables/artifacts, possible scopes/TTL, string/json types, ID-based reuse, error resilience, and the use of this mechanism by various external reasoning runtimes.

Conclusion for ChatGPT Integration

The current integration already allows ChatGPT to perform real work via the API, but it has revealed an important missing layer:

an addressable operational memory is needed between ChatGPT's reasoning context and the permanent domain entities of fi1osof.ru.

This is not a specific enhancement for the sake of a single worklog. It is an infrastructural requirement for multi-step agentic workflows, especially if a single agent identity can work through different cognitive runtimes.