翻訳待ち：Experiments with AI – Structure of Third Party Agentic Apps

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

This is a technical companion piece to building out an experimental app called CareLoop. What CareLoop is and why it was built is written here. With Careloop, I do not ship an app with functionality, I ship an expected shape of the output or the behaviour I need and the agent harness does the rest. I think of it as a new kind of app, a “Third Party Agentic App (TPAA)”. It is not a wrapper for a frontier model that is shipped as a stand alone app. It is not developed by the AI provider. But it is fully dependent on the AI provider and the harness (like Codex, Claude Code etc) that ships with it. Like ChatGPT et al, the primary interface of this app is a chat box, but the inputs can be anything and the output can also be anything. It is completely customized to what the user wants. There are no standard workflows or standard layouts/buttons etc. Designing Careloop has required me to stretch and change my way of thinking of how to think of programming and general app implementation design. There is much more focus on the higher level architecture of data shapes, expected behaviours, managing of exploding context and data and the required output from the AI. The detailed coding is relatively small part of the work now. I elaborate more on it below. It requires the following - Frontier AI model - chosen by user Default best fit agent harness for that model - Claude Code works best with Claude, Codex with GPT Sol, Kimi Work with Kimi models and so on. This is also chosen by the user. Third Party Agentic App (TPAA) - A self contained bundle of skills, scripts, database, along with the environment to execute code, that work from within the default harness. It cannot work outside of the agent harness. I think of it as drawing parallels to 3 layers of a consumer computing device - the hardware/LLM Model, the OS/harness and finally the classic third party app/TPAA. Before I go to the structure that describes TPAA - I want to emphasize that the end user of TPAA are non coders. As of today, these users currently fall into the category of tech enthusiasts because the distribution of the agent harness into general non technical audience has just begun. But any person will have their preferred harness to run this app. Peering into the future, I think that the harness will be a very capable on device agent running on the user’s phone. I can forsee this happening in the near future with reasonable certainty. Structure and Characteristics of TPAA As a developer I just have to describe the happy path, the agent does the rest for the user. This happy path is described and supported by the skills, scripts, execution environment, database shape and guardrails. Careloop has skills for data ingestion for different data types, guidance on how to process and store it along with ingestion scripts. This keeps the AI focused on the user problem without thinking about the required data shape etc. It has skills on triaging, researching and combining data to give a useful output. It is almost like another harness specific for that domain that works on top an existing harness. The app will work with any harness - this app is not custom built for any harness. It works with any AI agent and it requires a harness to run. Raw LLM models can’t run it. Careloop can be loaded into any agentic harness like Codex, Claude Code, Pi, OpenCode etc. Output varies with model/harness - The output of the app will vary based on the harness and the AI model. So the developer of the app has to factor in which model/harness is better for their use case. This will cause lot of variation in quality of user experience for the users. Careloop’s output varies substantially when it is used in Claude Code vs Codex. In fact, as of today (Aug 2026), Fable in Claude Code sometimes refuses to work due to the questions regarding health which apparently falls into their dangerous “bio” category. 🙄 It has 4 things to work properly - It has fully dynamic skills, scripts, execution environment configuration and database. Removing any of the above will break the functionality of the app. All 4 are modifiable by the AI and completely customized to the user, but scoped to its use case. Careloop has a bunch of skills that interact with each other on the fly to address a user’s medical need. It requires a bunch of pre-shipped scripts to do it efficiently and properly. It creates a venv to execute it securely and does not cause problems with othet things on the user’s machine. It can self heal safely - It self updates and self heals automatically while making sure that the dynamic database, execution environment and sub apps don’t break after the update. Careloop can self heal after an OS upgrade breaks the execution binaries available for that version. Careloop frequently modifies/tweaks the packages it installs for the user based on their request or their OS environment. It self heals when a quirky setting prevents itself from execution, like a configuration that conflicts with the user’s setup but just requires a couple line of changes - the app modifies itself to work with it. Compatibility support is significantly reduced from the developer’s standpoint since it “self heals”. It will fix a bad database, refresh it and will write code on the fly to do whatever the user needs them to do. The database is dynamic and incompatible with other users of the app - The database shape is shipped with the a default template by the developer, but it is built to be modified based on the user interaction on the fly by the agent harness. This means it is designed to diverge from the original database shape and mould itself to the user’s requirements. So over a period of time, every user’s database will be unique to that user and it is ok for it to be completely incompatible with any other user of the app. Careloop only ships with the empty database template and how it needs to be used. The actual querying and filling of data is done completely on the fly by wrting the code for it. There is very little execution code related to database operations compared to a classic app. The agent can also create and maintain entirely new tables that is very specific to that user. The execution environment is dynamic - Similar to the database, the app ships with an execution environment - think of a requirements.txt file with instructions for venv. But the skills allow the AI agent to install things on the fly to help the user. Careloop initially did not have support for handling MRI data - but it installed dicom libraries to read MRI images that the user gave. It just did it and helped answered the user’s query without any technical support from me as a developer. Execution happens on the user’s machine and with the default AI provider - the agentic app developer does not have a running cost. The app is sandboxed by default by the harness. This is very much the opposite of a classic non agentic app. The classic apps have standard data shapes and shared databases, standard (but customizable) UI, standard execution environment, stable experience and so on. Just like the development lifecycle of a regular app, based on feedback from the users, some of the common usecases will be incorporated by the developer and will be shipped in the futured updates of the standard app. Squinting at a plugin If you look at it, especially with a squiting eye, the above architecture is very close to how plugins are built too. But the key difference in Careloop vs a AI harness plugins like Ponytail, Caveman etc is that Careloop is the thing in itself. It has an execution environment that is stateful and with state of data. The core of Careloop is state of information that keeps on updating itself over its life as users use it. Plugins are stateless and ambient, TPAAs are not. I asked ChatGPT to describe the difference and here is what it said - The stronger distinction appears to be that a TPAA owns a persistent, user-specific domain environment and evolves it through agent action. New set of problems Designing TPAA is more meta programming rather than regular programming. Designing such an app requires a fundamentally different approach compared to the classic apps, everything is dynamic and it needs to be factored into every decision making in the design. There are several questions that are now open design issues in TPAA - The whole app runs on the user’s machine and the developer has to be much more careful in instructions for the AI so that it doesn’t go off rails. How does one design for that? How does the default harness ensure safety of execution of code and data? What happens to supply chain attacks in these kind of environments? Especially when TPAA is expected to dynamically install software for the user in the background to help the user’s query. How does the provider/harness handle Rogue apps / Malware? How does the developer communicate with the user on what sort of providers/harness works best with the app? Should the developer have control over what kind of providers/harness can use it? How will it get enforced? How does one design an architure that is compatible with so many moving pieces? Careloop has different experiences based on the combo of model/harness used for it. How does the quality of output get measured against various provider/harness/TPAA combinations? How does testing against it scale? Is evals a feasible solution for this? Since the user is paying for the harness/provider, how does the user control the token usage of TPAA? How does the developer guide the user about expected usage? I do not have clear answers to any of the above but these will need to be solved as more and more TPAA like structures get shipped across the board. I also do not know if TPAA is even the right way for developers to work with AI for their use cases. It is still far too early to call a winner for a standard way of distributing such software.