A single prompt can look like magic, but there’s far more behind an AI agent’s effective operation: context, tools, instructions, and a properly designed working environment. In this article, we show what’s really happening “under the hood” and how these elements shape what AI agents can do.
What looks from our vantage point like a single command is, in practice, only the start of a whole series of operations – regardless of which tool we use to bring our “vibe” to life. Our prompt is merely the starting point for everything that follows.
Whether we’re using Claude Code or the various models available in Opencode, we can peek at how our request actually gets carried out. The agent first processes the initial prompt, then, based on it, prepares the next step. That step becomes, in practice, the next prompt, whose result leads to another. In this way, the agent solves the task iteratively.
It’s worth noting that earlier prompts don’t disappear. They form a conversation history and together make up the context that’s talked about so often in the world of LLMs. Processing all that context – or more precisely, the tokens it gets broken down into – is expensive. That’s why the tools and organizations working on agents constantly optimize how it’s used: they employ caching, avoid reprocessing the same tokens, and try to cut down on unnecessary operations. A lot of people work very hard so that the user has the impression their input amounts to just a single prompt.
Another buzzword – though a more technical one – is the harness. It’s the set of tools, rules, constraints, and capabilities that the language model we’re using is “wrapped” in. Claude Code is an example of such an Agent Harness, as are Codex and Opencode. Even omo.dev, an extension for Opencode, is in practice an additional layer expanding its capabilities. The goal of every such “harness” is to guide the LLM in the right direction: providing MCP tools, access to the file system and other programs on the device, and an appropriate response when the context runs out.
The LLM is the brain, but on its own it has no hands to carry out tasks. You can see this even when using Gemini in a browser. The model will happily suggest which commands to run or which buttons to click, but it won’t do it for us. The right harness is exactly what supplies those capabilities. Of course, it’s the user who decides how much of them to make available to the agent. Practically every agentic coding tool has a permission system that lets you specify which operations are allowed, which are forbidden, and which the agent should ask about.
A harness is also a set of prompts. When and how should conversation-compacting operations be run so as not to exceed the available context? How should sessions with the LLM be named? How should the model behave, and in what way should it present its answers to the user? With Opencode, we can easily peek at the rules that govern a model “plugged into” this solution. The prompts are simply text files available in the code repository. From them we can learn, for example, that the agent generating conversation titles has a clearly defined task: don’t complain, just generate titles. In another file, we find an instruction that the agent should consider itself the best coding agent in the world. It’s hard to find a better embodiment of the “you’re a winner” idea.
Of course, Claude Code and Codex protect their internal prompts and work organization as much as they can. In fairness, though, it has to be said that they don’t always pull it off perfectly. We can nevertheless assume that their internal solutions don’t differ dramatically from what Opencode offers. An interesting case is the omo.dev mentioned earlier. Its creators boast that they’re the best, and as proof they point to the fact that their solution was supposedly responsible for blocking the ability to use a Claude subscription in Opencode. In their view, Anthropic’s model worked better through their plugin than in the original Claude Code. The ability to use Anthropic’s models still exists, of course, but now on a pay-per-token basis.
Whether that single plugin really was the reason for those restrictions, or whether more factors simply came together – it’s hard to say. Either way, it shows that how an agent is equipped matters.
AI accelerates application development. Productive24AI provides a consistent environment for deploying those applications.
So how do we do it? After all, we boast that with Productive24AI you can use Claude Code, Codex, Opencode, or Antigravity. If we integrate ready-made solutions, then where is our “harness”?
Here, Productive24AI is very close to the omo.dev approach. Just as its creators wrapped Opencode in their own tools, we do the same for all the available agents. The whole thing is made up of many layers that together make the agent “know what it’s doing” while working with the Vibe Configurator in Productive24AI.
We initialize the agent directly in the user’s repository. It sits exactly where it’s meant to work, with access to the resources needed to complete the task. It begins its work by loading a file of initial instructions that explains where it is and how the Productive24AI configuration works. This is a condensed dose of knowledge loaded with every conversation, so it has to contain everything essential while at the same time not needlessly clogging the context and wasting tokens.
Besides this initial “knowledge bomb,” we equip the agent with a set of skills that help it carry out specific tasks efficiently. Designing applications, preparing a work plan, editing documentation, handling permissions, or assisting with Git operations – these are all skills the agent will use when they’re needed. The user doesn’t have to know them all; the agent selects the right ones for the situation on its own. On top of that, it has “on hand” files describing the more complex elements of the system in detail. These aren’t always loaded, so as not to take up context, but they remain easily accessible whenever the need arises.
Tools are the most important part of our kit. Elements of the Productive24AI system often consist of several or a dozen-plus files of different types. The agent could create them all by hand, but that would be inefficient and costly in terms of tokens. Most of these files have a known structure that only needs to be adapted to the specific case. That’s why we provide tools for creating and modifying these elements. Some operations – for example, changing a single setting in many places – are far more efficient using system tools. The agent is instructed on how to optimize token usage in such situations.
We have files describing how individual system elements work, but nothing is as precise as the full platform documentation. That’s why we also provide tools for searching for specific information in the documentation. If something isn’t clear, a single tool call is all it takes for the agent to receive verified information. We work in the browser, and the agent is right there with us in the same window. When it does something, we can ask it to show us the result. When it finishes its work, it can send a notification. This is another layer of tools that simply makes the collaboration convenient.
GitOps, which we chose as the foundation of the P24 architecture, has many advantages. It’s not a philosophy that requires a PhD, but in fairness it has to be admitted that it isn’t something that comes entirely on its own, either. If the user wants to and grants the agent the appropriate permissions, the agent can perform these operations for them. Just ask for the change to be pushed to production, and the user will be guided through the deployment process and any conflict resolution.
In all, we offer three sets of MCP tools. They’re divided in a way that optimizes the size of the context. They provide full access to the platform’s capabilities – from a guide to the current page, through the Vibe Configurator that prepares the application, to a Git expert deploying changes and a controller checking the application’s compliance with requirements.
Of course, Productive24AI isn’t just a platform. From the user’s perspective, it’s above all the application and the configurations it contains. That’s why, together with the agent, we also make use of “Project Knowledge” – a document that can be edited on your own or with an LLM’s help. This is where we keep information, rules, and best practices for working with the configuration. If an organization wants to establish a particular way of working and expects the agent to enforce those rules, this is the ideal place to record such arrangements.
We built this solution the way we did because we know both Productive24AI and coding agents. We know what it’s like to work with them, and we understand the platform’s capabilities and limitations. The features described above don’t, of course, exhaust the whole spectrum of possibilities. We can create documentation for individual modules, hunt for bugs, generate change reports, prepare solution specifications, and carry out many other tasks. The aim of this piece wasn’t to show everything you can do in Productive24AI. We wanted to show something else: that this isn’t wizardry. It’s not an accident or the result of a “magic prompt” after which the system started working all by itself.
It’s a planned, carefully considered architecture – a set of knowledge, tools, rules, and processes that together make using any agent to work with Productive24AI as easy, fast, and predictable as possible.
An MVP in a few days!
Test what Productive24AI can do in your processes.
to our newsletter and stay up to date with new publications on the blog.
Try it out at no risk!
