Driving Pi with ChatGPT Sessions: MCP and Computer Use in Practice

Why Do We Need "Persistent Sessions"?

The AI coding agent Pi isn't lacking in capability, but what really affects the user experience often isn't the model itself — it's the context fragmentation between sessions. Every time you restart a conversation, the previous tool configurations, project background, and progress on ongoing tasks are lost, forcing users to repeatedly restate the same information.

This pain point isn't unique to Pi. Around AI agent "memory" and "orchestration," the community has already produced multiple approaches: some rely on long context windows brute-forcing through, some depend on external RAG retrieval, and others try to turn the session itself into a manageable object. The approach discussed in this article belongs to the latter — using ChatGPT tasks to organize discrete Pi sessions into continuously running workflows, and filling capability gaps with MCP tools and Computer Use.

Background to add: What are AI coding agents and MCP?

AI coding agents refer to intelligent systems that can autonomously execute code-related tasks. They don't just answer programming questions — they can read and write files, run commands, and call external services, thereby completing the loop from requirements to delivery. The effectiveness of such agents depends not only on the capabilities of the underlying large model, but also on whether it can maintain a correct understanding of the project and task state across multiple interactions. MCP (Model Context Protocol) is an open protocol proposed by Anthropic, aimed at unifying the way large models connect to external tools and data sources. Developers can write "tool servers" according to the MCP specification, allowing models to call file systems, databases, APIs, and other resources through standardized interfaces. The emergence of MCP reduces the cost of adapting tools for each individual agent and makes the tool ecosystem reusable — this is also the prerequisite for the solution in this article to efficiently combine Pi with external capabilities.

Core Mechanism: ChatGPT tasks as the Session Orchestration Layer

The starting point of this solution is straightforward: don't treat Pi as a "Q&A bot," but as a long-term worker that needs to be scheduled. ChatGPT tasks plays the role of orchestration layer here, responsible for recording task state, triggering new Pi sessions, and passing necessary context between sessions.

The value of doing this is transforming "context preservation" from a model capability problem into an engineering problem. The model doesn't need to remember everything — the orchestration layer is responsible for feeding the right information at the right time. Compared to relying solely on a larger context window, this approach is more controllable in long-cycle tasks and easier to debug — when problems arise, you can pinpoint exactly which session and which segment of context went wrong.

Connecting MCP Tools: Giving Pi External Action Capabilities

MCP (Model Context Protocol) tool integration is a key part of this solution. Pi itself excels at code-related reasoning, but to translate reasoning into actual actions — reading and writing files, calling APIs, operating external services — you need the tool interfaces provided by MCP.

You may not have noticed that the order and granularity of tool integration significantly affect stability. If too many tools are mounted at once, the model tends to hesitate or even misuse them during selection; too few tools, on the other hand, prevents tasks from closing the loop. In practice, a more reliable approach is to mount tools in groups by task type, keeping the tool set each session faces streamlined. This is consistent with current mainstream AI agent engineering experience: tool quantity and quality are equally important.

Background to add: The "context tax" in tool selection

In AI agent engineering, every tool mounted occupies the model's context window through its name, description, and parameter schema — this overhead is often called the "context tax." When the number of tools balloons, the model must choose among numerous candidate tools, which not only consumes more tokens but also easily creates ambiguity or mis-invocations; meanwhile, semantic overlap between tool descriptions further reduces selection accuracy. As a result, the industry has gradually formed the practice of "grouping on demand, dynamic loading": exposing only the most relevant small set of tools based on the current task type, and swapping the tool set when tasks switch. This aligns with the "mount by task type" idea mentioned in this article — the goal is to strike a balance between capability coverage and selection stability, rather than maximizing tool count.

Computer Use as the Fallback Bridge

Not all operations have ready-made MCP tools. The original text's "bridge gaps with computer use" is precisely targeting such cases — when dedicated tools are lacking, directly operating the graphical interface through Computer Use to complete the task.

This is a pragmatic trade-off. Computer Use is usually less reliable than structured tool calls and slower, but its coverage is nearly unlimited. Treating it as a fallback rather than a primary path allows you to extend Pi's capability boundaries without sacrificing stability. The criterion is simple: use MCP tools when available, and fall back to Computer Use only when they're not.

Background to add: How Computer Use works and its limitations

Computer Use refers to the technical approach of having an AI model understand graphical interfaces through screenshots and simulate mouse clicks, keyboard input, and other operations to complete tasks. It doesn't depend on the target software providing APIs or dedicated tools, so in theory it can operate any program with a graphical interface, offering extremely broad coverage. But its limitations are also obvious: each step requires screenshotting, recognition, decision-making, and execution, resulting in a long loop chain and slow speed; interface element recognition can go wrong, and pop-ups, loading delays, and dynamic layouts all introduce uncertainty; additionally, sensitive operations come with permission and security risks. Therefore, Computer Use is better suited as a fallback when structured tools are missing, rather than a daily first choice. The criterion is exactly as stated in the original text: use MCP tools when available, and fall back to Computer Use only when they're not.

What "Delivering Work Without Losing Context" Means

The original text emphasizes the ultimate goal of delivering work without losing context. Breaking this down reveals two layers of requirements: first, tasks can truly be completed and produce deliverable results; second, the context accumulated during completion doesn't evaporate at delivery time.

The second point is often overlooked. Many AI workflows appear to have completed their output, but the process information is scattered across multiple sessions, making it impossible to reuse or audit. Once sessions are organized into stateful workflows, the context itself becomes an asset — the next similar task can stand on the shoulders of the last one, rather than starting from scratch.

Who This Solution Is For

This orchestration approach is better suited to scenarios with long task cycles and heavy context dependencies, such as continuously maintaining a code repository, tracking a set of configurations that need repeated adjustments, or handling workflows involving multiple external systems. For lightweight Q&A needs, introducing an orchestration layer only adds complexity.

From a broader perspective, this case reflects a common direction in the AI agent field: beyond model capabilities, how to organize sessions, connect tools, and manage state is becoming a key variable determining actual results. The combination of Pi and ChatGPT tasks is just one specific implementation — the orchestration thinking behind it has broader reference value.

One-line Summary

Orchestrating Pi sessions with ChatGPT tasks, combining MCP tools and Computer Use to achieve continuous delivery without losing context.

Paragraph Summary

The article discusses how to solve the pain point of context fragmentation between sessions in the AI coding agent Pi. The solution doesn't rely on a larger context window or RAG, but instead treats ChatGPT tasks as a session orchestration layer, organizing discrete Pi sessions into stateful continuous workflows, where the orchestration layer is responsible for recording state, triggering new sessions, and passing context. On the capability front, MCP tools give Pi external action capabilities such as reading and writing files and calling APIs, and it emphasizes that tool integration needs to control quantity and granularity, mounting by task group to maintain stability; when dedicated tools are lacking, Computer Use operates the graphical interface as a fallback. The core goal is to deliver work results while preserving reusable context assets. This solution is suited to long-cycle, context-heavy tasks, and is not applicable to lightweight Q&A needs.