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.