Practical Experience of Integrating ChatGPT ↔ fi1osof.ru ↔ haih-agent

Economic Motivation

The main reason for integration is the cost of LLM calls in haih-agent. Each request to the model is billed separately, and strong models, large context, and long reasoning/tool loops make work noticeably more expensive. In ChatGPT, under a subscription model, one can conduct a long interactive dialogue and perform a significant amount of reasoning without constant budget control for each request.

Hence the primary need: use ChatGPT as a cost-effective interactive environment for reasoning and working with real fi1osof.ru data, while maintaining the identity, memory, and autonomous capabilities of haih-agent.

Important: haih-agent is already a full-fledged agent runtime. ChatGPT is needed not because the agent lacks reasoning, tools, or memory, but because interactive reasoning inside ChatGPT is more economically viable.

Why Custom GPT + Actions Was Chosen for a Quick Start

The main criterion for the initial choice was a quick start.

The fi1osof.ru side already had an HTTP/GraphQL API, so the shortest path turned out to be a Custom GPT with an Action that sends an HTTP POST to fi1osof.ru.

Practically without backend modifications, ChatGPT gained access to the real system. The universal GraphQL Action scheme proved particularly successful: instead of a large number of separate REST actions, ChatGPT can send an arbitrary GraphQL document, and if the structure is unknown, first perform introspection.

The strong point of the old Actions mechanism is that ChatGPT itself helps set up the integration: it drafts the OpenAPI config, helps parse the API and response structures, and suggests schema changes. Due to this, you can quickly connect to almost any HTTP API, REST, or GraphQL, without special backend adaptation.

Experience with MCP

We already have an MCP server on our side, but connecting via ChatGPT turned out to be significantly less transparent.

The main problem is the lack of proper diagnostics. When an error occurs, only a general text is visible, but HTTP status codes, response bodies, headers, detailed causes, handshake stages, and other data that would help quickly understand what is going wrong are missing.

The second problem is the lack of an agentic setup mode for the integration itself. In Actions, the agent helps assemble and fix the config, while in an MCP connection, it practically cannot see the internal error and cannot investigate the problem itself. As a result, the connection feels like a black box, and a quick start failed even with a ready-made MCP server.

Limitations of Custom GPT + Actions

Single Config per Domain

You cannot add several separate Action configurations to the same domain. This forces combining different capabilities into a single OpenAPI schema, even if logically it would be more convenient to separate them.

Strict Path Limits

A very small configuration/description limit applies to a single path, around 300 characters. Because of this, several actions could not be conveniently described via a single /api/ path, and multiple paths had to be created, even though on the backend they can all still be wrapped into a single GraphQL endpoint.

Legacy Risk

Actions look like a legacy direction with an unclear long-term prospect. This makes them a good tool for a quick start, but a risky foundation for the final architecture.

Custom GPT Isolation

Custom GPT operates as a separate isolated chat and does not have full access to other features of the main ChatGPT environment, in particular Projects, Library, and parts of the general workspace context. This limits the value of the integration because API access is present, but some of the strengths of chatgpt.com itself are lost.

What Has Already Been Actually Accomplished Through the Current Integration

The current scheme has already proven its viability in real scenarios.

Through GraphQL Action, it was possible to:

• get a list of projects;
• perform GraphQL introspection;
• get the current user/agent;
• read users to determine the assignee;
• explore input types and enums before mutations;
• create tasks;
• assign tasks to a user or agent;
• create worklogs;
• update task statuses;
• complete tasks after checking the result.

Practically, a complete end-to-end cycle was passed:

discovered a problem
→ created a bug report
→ re-checked the API after the fix
→ added a worklog
→ moved the task to Done

Also, in the course of actual work, tasks were created for:

• fixing implicit project list filtering;
• admin editing of other people's tasks, projects, and worklogs;
• displaying the creator and assignee in the task list and card;
• long-term memory and the AI agent's lifecycle;
• the current ChatGPT integration with fi1osof.ru and haih-agent.

A working format has already been established for tasks:

• description — a brief summary;
• content — the main detailed problem statement in Markdown.

Interaction with haih-agent

In the current integration, there are two different loops:

ChatGPT → directly via GraphQL → fi1osof.ru

and

ChatGPT → haih-agent → its own reasoning/tools

There is a fundamental economic difference between them.

If ChatGPT performs reasoning itself and makes API calls directly, the additional haih-agent LLM runtime is not needed, and there are no new paid LLM requests on the agent side.

If a task is handed over to haih-agent entirely, it can run its own reasoning/tool loop, and the cost starts depending on the model and the number of steps again.

Therefore, chatWithAgent is useful as a channel to the agent's own runtime, but it is economically disadvantageous to use it as a universal path for all operations.

Architectural Conclusion from Practical Experience

Practice shows that an agent's reasoning runtime and its identity/memory/runtime do not have to be the same component.

The same agent entity in fi1osof.ru can potentially receive intelligence from different sources:

• ChatGPT;
• its own haih-agent runtime;
• an external API model;
• a local model.

At the same time, tasks, knowledge, worklogs, identity, and history can remain in the common system.

This opens up the possibility of economic optimization: perform interactive work where reasoning is cheaper for the user, and leave autonomous work to haih-agent.

Current Conclusion on Integration Mechanisms Inside chatgpt.com

Custom GPT + Actions

Pros:

• very quick start;
• required almost no backend changes;
• the agent helps set up OpenAPI;
• suitable for both REST and GraphQL;
• reasoning stays within the ChatGPT subscription;
• has already proven viability in real read/write scenarios.

Cons:

• one Action config per domain;
• strict path limits;
• having to adapt the API shape to ChatGPT limitations;
• Custom GPT is isolated from the main ChatGPT environment;
• there is a risk that Actions will be further supplanted by newer mechanisms.

ChatGPT App / MCP

Potential pros:

• a more modern and standardized integration method;
• natural tools/resources model;
• potentially deeper integration with the ChatGPT interface;
• MCP server already exists on our side.

Practical problems of the current ChatGPT implementation:

• poor connection diagnostics;
• lack of transparent debug output;
• errors without sufficient technical details;
• the agent does not help debug the connection itself;
• because of the black box, the quick start turned out worse than via Actions.

Main Outcome of the Stage

Actions were chosen not because they are the best long-term option, but because they provided the minimal path from the existing API to a working integration.

This choice fully justified the quick start criterion: without major backend rework, ChatGPT can already read and modify fi1osof.ru working data and participate in the real task lifecycle.

At the same time, operation showed that Actions have serious product limitations, and Custom GPT is too isolated from the main ChatGPT environment.

MCP is potentially better suited as a long-term direction, but the current connection UX and lack of proper debugging inside ChatGPT create a high barrier to entry.

Specific architectural decisions for the further development of the integration should be recorded in separate worklogs after experiments, rather than considered pre-selected.

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.

Hypothesis: Custom GPT can provide an almost free, fully functional intelligence layer on top of haih-agent

Observation

During active work with Custom GPT on the ChatGPT Plus plan over several days, an unusual pattern is observed: despite a large number of dialogues, reasoning, calls to Actions, GraphQL queries, and long contexts, the displayed usage practically does not decrease and remains around 99% remaining.

This cannot yet be considered proof of unlimited or completely free GPTs usage. Potential hidden limits, different usage accounting systems, rate limits, or quotas that are not reflected in the observed indicator remain possible.

Nevertheless, the practical observation is consistent enough to establish it as a working hypothesis.

Hypothesis

If it is confirmed that intensive work via Custom GPT within the ChatGPT Plus subscription actually consumes almost no separate noticeable quota or financial budget, then the combination of:

ChatGPT Custom GPT
+ Actions / integration layer
+ fi1osof.ru
+ haih-agent

can provide an almost free in terms of user economics, fully functional intelligent service for a large class of applied tasks.

This is not just about chat or text generation. In our current integration, ChatGPT can already work with real entities and system tools, meaning it is potentially capable of performing full-fledged intellectual work on top of data.

Potential Scenarios

If the hypothesis is confirmed, such a loop can be used for:

• project and task management;
• preparing and editing task specifications;
• creating worklogs and reports;
• generating meaningful high-quality content;
• analyzing large volumes of data;
• exploring related entities;
• comparative analysis;
• anomaly and contradiction detection;
• preparing conclusions and hypotheses;
• processing long contexts;
• working with the knowledge base;
• analytical and research tasks that could cost a noticeable amount of money via a regular LLM API.

Using ChatGPT as a cheap reasoning runtime is especially interesting for tasks where the main cost is usually generated not by a single response, but by a large number of sequential steps: reading data, clarifications, intermediate analysis, re-checks, and long reasoning chains.

Why this works specifically in combination with haih-agent

ChatGPT on its own does not completely solve this problem.

Its economic advantage becomes truly valuable only when it has access to a full-fledged agent infrastructure.

In our case, this role is performed by haih-agent and its associated fi1osof.ru infrastructure.

It already provides what a regular ChatGPT lacks to transform into a working service:

• persistent agent identity;
• access to projects, tasks, and worklogs;
• GraphQL API;
• skills;
• MindLog and other memory mechanisms;
• knowledge base;
• data reading and modification tools;
• the ability to interact with the agent's own runtime;
• means of integration with external systems;
• server rights and access control;
• the ability to save work results in the system rather than leaving them only in chat history.

That is, the economic effect arises not from ChatGPT separately and not from haih-agent separately, but from their combination:

ChatGPT
= economically cheap reasoning and interface for the user

haih-agent / fi1osof.ru
= memory, tools, data, identity, API, actions, and integrations

Together, this potentially turns into a full-fledged working environment where expensive intelligence can be used much more intensively than with direct payment for each LLM API call.

Particularly Interesting Scenario: Analysis of Large Data Volumes

If usage is indeed practically unconsumed, then ChatGPT becomes a potentially very cheap tool for iterative analysis of large arrays of information.

Importantly, this does not necessarily mean loading the entire volume of data into a single context. haih-agent/fi1osof.ru can provide tools for search, filtering, pagination, sampling, knowledge spaces, and other methods of gradual data access.

Then ChatGPT can work iteratively:

retrieve a portion of data
→ analyze
→ formulate the next query
→ retrieve the next sample
→ compare results
→ verify hypotheses
→ save conclusion

With API pricing, such a multi-step cycle can be expensive, especially on a powerful model. Within subscription-based ChatGPT, its economics are potentially radically better.

Limitations of the Hypothesis

It cannot yet be stated that:

• Custom GPTs are completely unlimited;
• usage will never decrease;
• OpenAI will not change the limits model;
• the current indicator reflects precisely the resources consumed by the GPT;
• intensive scenarios will not hit other rate limits or hidden caps.

Therefore, this is currently a hypothesis based on practical observation, rather than a guaranteed property of the platform.

What Confirmation Will Mean

If the observation is confirmed over a longer interval and with different types of intensive work, the integration acquires additional strategic value.

It will solve not only the task of convenient ChatGPT access to the agent, but also the task of radically reducing the cost of intellectual work.

In this case, ChatGPT can be viewed as a very cheap external cognitive runtime for haih-agent, while all stable infrastructure — data, memory, identity, tools, permissions, and results — is preserved in fi1osof.ru.

This potentially opens up the opportunity to build services on top of haih-agent that use strong ChatGPT models for reasoning quality, but are closer in economics to a fixed subscription than to traditional LLM API token-based billing.