Context

When integrating ChatGPT with fi1osof.ru, a systemic issue was discovered: ChatGPT can generate large amounts of intermediate content and execute a sequence of API calls, but it lacks a convenient reusable addressable working memory that can be referenced between individual Action calls.

In practice, this manifested when creating a large worklog. The worklog text was generated once, but upon a retry, it had to be passed in full again inside the GraphQL variables. If an operation fails, is retried, or is used in another context, the exact same large payload has to be transferred through the ChatGPT Action all over again.

The problem goes beyond worklogs. It applies to any intermediate reasoning results that need to be used more than once.

Core Need

A universal mechanism is needed that allows an external AI client to first save an arbitrary value as an independent addressable object, and then use a reference to it in subsequent operations.

Conceptually:

create variable / artifact
→ get ID
→ use ID in other actions

Example:

var_abc123 = "# Large Markdown..."

and then:

create worklog
content = var_abc123

or:

create task
content = var_abc123

Why Standard GraphQL Variables Are Not Enough

GraphQL variables live only within a single HTTP request.

They do not provide the ability to:

• save the result of one step and reference it in the next;
• reuse large text without re-transmitting it;
• address an intermediate result by ID;
• separate the "generate → verify → use" stages;
• restore a working object after an error or a retry;
• pass the same artifact to multiple operations.

Why the Current ChatGPT Dialogue Doesn't Solve the Problem Either

Text in the chat history is available to the model as context, but it is not a fully addressable API object.

You cannot reliably perform an operation of this level:

take specifically the Markdown that was generated two steps ago,
and pass it as content without regeneration/re-assembly

At the Action level, the actual argument value is still required, and the large text ends up in the payload once again.

The dialogue history is also not a stable programmatic interface for storing artifacts.

Why This Should Not Be Solved with Separate Domain Entities

Intermediate text could be saved as a Task, File, Fact, Draft, etc., but this creates unnecessary semantics and clutters the domain model.

The intermediate working state must be universal and independent of whether it is subsequently used for:

• a worklog;
• a task;
• a comment;
• a GraphQL mutation;
• transmission to another agent;
• a JSON config;
• a list of IDs;
• a query result;
• a large Markdown;
• temporary analysis.

Proposed Abstraction

It is important not to cling to the word "file". What is needed is a persistent addressable artifact / variable / workspace value.

The minimum model might look something like this:

id
name?
type
value
scope
createdBy
createdAt
expiresAt?

For the first stage, the following types are sufficient:

string
json

Later on, binary/file/reference and other options can be added if necessary.

Lifespan

It is useful to distinguish at least two modes.

Session / temporary

For short-term working state:

• intermediate results;
• large texts;
• query results;
• prepared payloads.

Can be automatically deleted via TTL.

Persistent

For artifacts that need to be used between sessions or stored long-term as a working object.

Possible Usage Model

Step 1. Save the value

createVariable(
  name: "integration_worklog",
  value: "# Practical integration experience...",
  type: "string"
)

Response:

var_abc123

Step 2. Use the value

Option A — specialized field:

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

Option B — universal reference inside an argument:

{
  "taskId": "...",
  "content": {
    "$var": "var_abc123"
  }
}

Before calling the domain resolver, the intermediate layer resolves $var into the actual value.

How exactly to implement resolution is a separate architectural question. In this task, the requirement itself and the universality of the mechanism are more important.

What This Provides to External AI Clients

1. Reuse of large results

Large Markdown or JSON is transmitted once, after which it is used via a short ID.

2. A proper multi-step workflow

It becomes possible to separate the process into:

generate
→ save
→ verify
→ edit if necessary
→ use
→ reuse

3. Error resilience

If the final mutation fails, there is no need to regenerate or re-transmit all the initial content. You can retry the action with the same variable ID.

4. Context and payload savings

The volume of repeatedly transmitted data between ChatGPT and the backend is reduced.

This is especially important for long:

• worklogs;
• task descriptions;
• reports;
• research results;
• JSON configurations;
• entity lists.

5. Universality

A single mechanism works for different AI clients and different operations, not just for ChatGPT or worklogs.

It can be used by:

• ChatGPT Actions;
• ChatGPT App / MCP;
• haih-agent;
• other external agents;
• IDE agents;
• local models.

Important Architectural Property

This mechanism effectively becomes the workspace/runtime state for the external reasoning runtime.

The external agent thinks and generates intermediate results, while fi1osof.ru/haih-agent provides it with addressable operational memory that exists independently of a specific LLM call.

This is especially important for architectures where a single agent identity can use different cognitive runtimes.

What Needs to Be Considered

• API for creating, reading, updating, and deleting variables;
• owner/createdBy;
• scope and access permissions;
• TTL and auto-cleanup of temporary values;
• size limits;
• string/json types;
• secure variable resolution;
• protection against recursive references;
• audit trail;
• ability to use a variable as an argument in different mutations;
• behavior when a variable is deleted or expired;
• whether versioning should be supported;
• whether private/session/agent/project scopes should be distinguished.

Acceptance Criteria

An external AI client must be able to execute the following scenario:

1. Generate a large Markdown.
2. Save it once as an addressable value.
3. Receive a short ID.
4. Execute several independent API operations, passing only this ID.
5. Retry a failed operation without re-transmitting the original Markdown.

At the same time, the mechanism must not be tied to a specific entity like TaskWorkLog and must be suitable as a universal working memory for agentic workflows.