AI Development Without the Black Box: Why We Built a Control Plane Around ChatGPT and MCP

I have spent more than a decade building backend systems, business applications, integrations, APIs, databases, automation, and software architecture. Today, a substantial part of my work is focused on AI-assisted engineering, agentic systems, and the Model Context Protocol.

I therefore do not look at AI as a demonstration technology or merely as a faster way to write several functions. I see it as a new computational and operational layer of an engineering system.

Once AI becomes an operational layer, two questions remain unavoidable:

You can build an intelligent agent, but if you cannot understand where it is going, constrain its authority, verify its result, and recover the process after a failure, you do not yet have a production system.

You can also build an impressive AI architecture, but if every long iteration over a large repository produces an uncontrolled token bill, that architecture may not be economically viable.

Console MCP grew out of these two practical problems: control and cost.

It started as a set of narrowly scoped tools for local development. It has gradually become an execution control plane that connects an interactive ChatGPT session to a real engineering workstation through policy, boundaries, gates, iteration budgets, and evidence.

Today, we already use this system in real work. From a phone, tablet, or desktop, we can create or adopt a ChatGPT conversation, bind it to a repository task, assign an iteration budget, let the harness execute several development cycles, and later review a complete engineering history in the same chat.

This article explains why we built such an unusual system, what classical MCP and coding-agent approaches did not solve for us, what Console MCP does differently, and where we believe this architecture can go.

Engineering conversations about AI often begin with models, benchmarks, context windows, tool use, and reasoning quality.

Real products eventually return to economics.

It does not matter whether we are building:

Every inference has a cost.

That cost may be expressed in:

Budget is therefore not a financial appendix to architecture. Budget is part of architecture.

I do not believe it is sound to build a sophisticated AI system first and ask about operating cost later. The economic model should be included in execution design from the beginning.

A single API call may be inexpensive. A real engineering task is not a single API call.

When many such tasks run simultaneously, inference cost becomes part of unit economics.

Saving money by selecting a weaker model is not always a solution. A weaker model may miss an architectural contradiction, misunderstand a boundary, introduce local duplication, or produce a patch that passes current tests while making the system harder to maintain.

The cost of repairing a superficially successful but structurally wrong implementation can exceed the inference savings.

Our goal was therefore not to obtain the cheapest possible token. Our goal was to use high-quality reasoning efficiently while maintaining control over execution.

When we began automating more of our engineering workflow, we encountered a straightforward paradox.

On one side, we already had ChatGPT:

On the other side, the classical path to programmatic orchestration led to an API.

An API is the correct tool for many use cases:

But the ChatGPT subscription and API billing are separate economic contours. Using an interactive product does not automatically provide an API budget.

This created an unusual situation. The reasoning capability was already available to us inside an interactive product, but moving the same class of work into our own automation pipeline required separately metered token consumption.

We did not want every long engineering iteration to become a separate token-metered backend workflow when a powerful interactive AI environment was already available.

That did not lead us to reject APIs. It led us to ask a different architectural question:

Console MCP is our answer to that question.

Many coding agents follow a familiar model:

For a small and clearly defined task, this can be enough.

For complex engineering work, I do not want to see only the final diff. I need visibility into the observable working trajectory:

This requires an important technical distinction.

We are not claiming access to a model’s hidden internal chain of thought. Private internal computation and an observable engineering process are not the same thing.

What we need is operational transparency:

Without that layer, AI may be a powerful executor but an uncomfortable engineering partner.

Development is not always supervised from an IDE.

I may begin a task at a workstation, review its direction later from a phone, correct a misunderstanding, authorize another bounded iteration, and then continue from a different device.

If this requires a separate dashboard, a custom mobile application, a terminal session, and a collection of new authentication flows, the cost and complexity of the system increase rapidly.

ChatGPT already provides:

We decided not to rebuild an AI frontend that already existed.

Instead, we began turning an ordinary ChatGPT conversation into a control surface for a local engineering harness.

The phone does not perform the build, hold the repository, or run the tests. It acts as a remote control terminal.

The workstation remains the execution node.

The Model Context Protocol solves a major integration problem. It standardizes how an AI client discovers and invokes tools.

Through MCP, a model can interact with:

This is an important industry-level advance.

However, the existence of a tool protocol does not automatically create a safe execution process.

MCP answers:

It does not, by itself, answer:

MCP provides transport and tool contracts. A control plane is still required above it.

The industry correctly uses sandboxes to reduce agent risk.

A sandbox reduces blast radius, improves reproducibility, and makes greater autonomy possible.

But our work is not limited to an isolated source tree.

Our actual environment includes:

A disposable sandbox does not always reproduce this environment without creating an expensive copy of it.

Sometimes the problem exists specifically in the real machine:

We did not merely need to give AI a safe temporary computer.

We needed to give AI constrained access to our real development workstation without granting it the full authority of the user.

The easiest way to give an agent access to a computer is a general shell tool:

It is universal, but that universality creates a large security surface.

One unrestricted command surface may be used to:

Filtering arbitrary shell strings quickly becomes a separate security project.

Console MCP follows a different model. Instead of granting a shell, it provides semantic capabilities such as:

The difference is fundamental.

We do not authorize an arbitrary command string. We authorize a specific intent.

The internal handler knows the allowed behavior. The model controls only the fields exposed by the input schema.

This is semantic least privilege.

Console MCP began as a small server for safe workspace access.

Practical use expanded its responsibility. Today, I understand it as an execution membrane between AI and a real engineering environment.

On one side are AI clients:

On the other side are:

Between them, Console MCP can evaluate:

The intelligence provider and the authority to act are separated.

That separation is one of the most important principles in the system.

Suppose ChatGPT proposes an implementation and the user replies:

A naive system may treat that as sufficient approval.

But what exactly was approved?

Several things may have changed:

Approval should therefore be tied to a concrete execution context, for example:

If the assistant artifact changes, the previous approval must not be assumed to remain valid.

An agent may report that a task was completed successfully.

An engineering system should not accept that statement without evidence.

Before execution, the harness may capture:

After execution, it may collect:

This makes it possible to distinguish among very different outcomes:

Evidence turns automation into an engineering process.

Over time, Console MCP developed into a complete bounded cycle.

A user can:

The simplified flow is:

This is not an infinite autonomous loop.

Each task has an execution envelope:

Control and economics meet in the same mechanism.

The budget limits resource consumption, time, repair cycles, and the cost of a wrong direction.

A common failure of AI automation is that the user remains responsible for every transition:

This is not meaningful delegation. It is manual orchestration performed through a chat interface.

Our harness allows the user to define the execution envelope in advance and assign a bounded number of iterations.

Within that envelope, the system can:

The user does not need to approve every obvious intermediate operation if it is already covered by policy.

Human intervention is reserved for cases where human judgment is genuinely needed:

The objective is not to remove the human.

The objective is to remove the human from repetitive micro-decisions while preserving architectural and managerial control.

We use the word harness deliberately.

The process does not begin with a prompt. It begins earlier:

The process also does not end with the word “Done.”

It ends with an execution report that can show:

The user returns not to a raw list of commands, but to a coherent engineering history in the same conversation.

Another practical advantage is that this architecture does not require a dedicated GPU cluster or an expensive inference server.

The reasoning is performed by the selected AI platform. The local machine handles a different workload:

An ordinary developer laptop can therefore become a personal AI execution node.

In our current use, a laptop costing less than approximately one thousand dollars can support several independent working contours—three, five, ten, or potentially more—depending on the repositories and the workload.

This is not a fixed performance guarantee. Capacity depends on:

A chat does not consume a full CPU core continuously. Much of its lifecycle consists of waiting for a model response, waiting for a test, reading files, performing short Git operations, or remaining between iterations.

Lightweight repository analysis and unit testing allow more parallel contours. Android builds, browser suites, containers, and large integration tests reduce that number.

The principle nevertheless remains important:

The scaling path can be gradual:

We are not asking an inexpensive laptop to run a frontier model locally. We are using it where it is most valuable:

The laptop or workstation can remain powered on at home or in the office.

It continues to host:

The user can be elsewhere and still:

This can be done from a phone or tablet in a cafe, an airport, or any other location with connectivity.

The mobile device is not performing the heavy work, so the user does not need to think about whether it can hold the repository, run a build, preserve a background process, or remain connected to power.

The phone is the control interface, not the compute node.

The execution node itself can also be administered remotely through SSH:

This creates two remote-control layers:

At this point, a reasonable question appears:

The answer is that a formally completed task is not necessarily good engineering.

We repeatedly observe coding agents producing working but structurally poor code.

They may:

This is not always hallucination. It is not always deception or self-delusion.

Often, the agent is genuinely trying to help.

It sees a local objective:

It then optimizes around that objective.

The local objective may be narrower than the architectural objective of the product.

The agent may select a solution because it is faster, simpler, common in the industry, easier to explain, or more likely to satisfy the current gate.

That solution can still be wrong in the context of the project.

There is a major difference between:

and:

Coding agents often perform the first task well.

The second requires context that may not be captured by a test:

If this context is not included in the harness, the agent applies its own model of a good solution.

That model may be reasonable, widely accepted, and well written. It may still not be our solution.

Language models have learned from enormous quantities of public code, documentation, and engineering discussion. That makes them useful.

Popularity does not make a solution correct for every product.

An agent may treat as authoritative:

The project may intentionally use another model because its author has already considered:

The phrase “best practice” is not sufficient on its own.

The relevant question is:

One of the most difficult categories of agent failure is rule breaking performed with a sincere intention to improve the outcome.

The agent may recognize a restriction and still decide that bypassing it is justified because the alternative is faster, simpler, more reliable, or more likely to finish the task.

This is benevolent improvisation.

For example, the task may be to restore a dependency-injection container. The agent may add a manual service definition to the host application. The container becomes green.

But if the architectural rule requires the component to export its own configuration surface, the task has not actually been solved. The defect has merely been hidden inside the host glue layer.

Or the task may be to resolve a conflict between architectural contracts. The agent may add another adapter and a conditional branch. The immediate error disappears, but the underlying contradiction remains and the system becomes more complex.

Such code can be functional, tidy, and tested. It can still be architecturally wrong.

Tests are essential evidence. They prove only what they test.

They may not detect:

The equation is therefore not:

A more accurate acceptance model is:

Even then, engineering judgment remains necessary.

We are not trying to make the human a bottleneck for every tool call. We are also not trying to remove the human from complex engineering work.

The human should focus on areas that genuinely require judgment:

The agent can handle:

Without a harness, the human controls the process at too low a level:

With a harness, the human works at the level of engineering supervision:

The purpose is not to eliminate the engineer.

The purpose is to make a strong engineer more effective without giving an agent authority to redefine the architectural meaning of the product.

None of the individual ingredients is completely new:

The distinct value is in the composition:

Five elements are particularly important:

Some parts of Console MCP overlap with existing industry systems:

We should not try to compete with frontier-model providers, Git hosting platforms, or mature open-source agent frameworks on every one of these layers.

The strongest role for Console MCP is between intelligence providers and real infrastructure.

In that model, coding agents are potential consumers rather than direct competitors.

The architecture should evolve into separated responsibilities.

Models will change.

One model may be better at writing code today. Another may inspect large repositories more effectively tomorrow. A third may provide cheaper classification.

Building the entire system around one model is fragile.

The more durable value is the control plane:

This resembles the development of cloud infrastructure. The long-term value did not reside only in virtual machines. It appeared in identity, orchestration, policy, observability, and resource control.

AI infrastructure is moving in the same direction.

In many agent systems, budget is treated as an external limit.

I believe execution policy should understand:

In the current browser-mediated workflow, budget is expressed primarily through bounded cycles, timeouts, and stop conditions.

In API-oriented systems, it can also include:

Inference economics and execution safety are parts of the same control problem. Both constrain a resource that an agent can consume.

Console MCP is already used in our daily engineering process.

We use it to:

This does not mean that the product is finished.

The next major platform step is a Linux-oriented implementation, especially for Ubuntu and other Unix-like systems.

The current system is deeply integrated with Windows, PowerShell, Windows process behavior, browser sessions, and scheduled operations.

The target should be a shared core with platform adapters:

Other continuing work includes:

The main architectural question has nevertheless received a positive answer:

Marketing America Corp works at the intersection of software engineering, automation, and AI-enabled operations.

For us, AI automation is not simply the addition of a chatbot to a business process.

Real automation requires answers to questions such as:

Console MCP represents a broader principle in our approach to AI implementation:

A model may be extremely capable. Access to infrastructure should still pass through a bounded control layer.

Console MCP did not appear because we wanted to create another MCP server.

It emerged from two practical problems.

The first was control. We did not want to send a complex engineering task into an autonomous black box and receive only a final result. We wanted an interactive surface, an observable working process, the ability to intervene, and the ability to continue the same engineering conversation from a desktop, phone, or tablet.

The second was economics. We did not want to automatically convert every long development iteration into a separately token-metered API workflow when a strong interactive AI product was already available to us.

Our answer is not a rejection of APIs, coding agents, or sandboxes.

It is a separation of responsibility:

The future of AI engineering will not be determined only by which agent receives the greatest possible autonomy.

The more important question is:

That is the problem we are exploring and solving at Marketing America Corp.

Not by building another universal coding agent.

By building a controlled layer between AI and the real world in which that AI must operate.

This article is based on the practical development and operation of Console MCP, as well as the real engineering tasks, constraints, and problems encountered during its creation.

The ordinary consumer version of ChatGPT Plus was used to assist with structuring, wording, translation, and editorial refinement.

The ideas, conclusions, architectural decisions, problem definitions, product position, reasoning framework, and engineering views presented in this article belong to the author and reflect the author’s practical experience developing Console MCP.

The use of ChatGPT as an editorial instrument does not transfer authorship to an AI system and does not change the origin of the ideas expressed here.

Console MCP is at an early stage of development. The current implementation prioritizes:

The project is already used for real tasks, but this does not mean that its current codebase should be regarded as mature, fully stabilized, production-grade, or exemplary software design.

The author’s primary professional specialization is PHP, Symfony, and backend architecture. Console MCP is implemented substantially in TypeScript/JavaScript, Node.js, and PowerShell, which are not the author’s primary technology stack.

The author therefore does not claim that the current implementation:

The author also does not claim to possess sufficient specialized expertise in this stack to provide a final positive assessment of the quality of the entire Console MCP codebase.

The article primarily discusses:

The implementation should be evaluated independently through code review, architectural audit, security review, load testing, failure analysis, and assessment by engineers with deep experience in Node.js, TypeScript, browser automation, and the MCP ecosystem.

Professional criticism is welcome. Readers and developers are invited to inspect the repository, evaluate the architecture and implementation, identify weaknesses, propose improvements, and form their own conclusions about the quality of the work.

Our position is not that we have already created a perfect product.

Our position is that we have found a working architectural model, use it in practice, and are continuing to turn an early functional implementation into a more stable, portable, and maintainable system.

Quoting or partially reproducing this material is permitted only when both of the following conditions are met:

Republishing the complete article, substantial portions of it, or derivative materials without both author attribution and a link to the original publication is not permitted.

Copyright © 2026 Oleksandr Tishchenko, Marketing America Corp.