From Chatbot to Sparring Partner: My Experiment with a Personal AI Growth Agent

I do not want another chatbot that forces me to re-explain my projects every time we talk. I want a sparring partner that knows my goals, tracks my progress, and notices when I tell myself the same excuse for the third time.

That is the starting point of an experiment I provisionally call my AI Growth Agent. This is not a finished product, and it is not an attempt to create a complete digital twin of my life. It is a practical research question: Can an AI genuinely serve as a demanding sparring partner over a longer period of time – or does it remain, even with memory, data access and voice interaction, little more than a convincingly fluent assistant?

I am writing this at the beginning of the experiment. I do not yet have conclusive results. What I do have is a clear intention, a growing architecture, and a gap between vision and daily practice that I want to make visible rather than hide.

Why I am building this system

The way I want to interact with such a system is not through forms or dashboards. It is through natural conversation – ideally by voice. The vision is simple: in the evening I talk with the agent. Together we review what I did today, what I intended to achieve, what worked, and where I avoided the hard part or got stuck. We examine what I actually understood, which assumptions were confirmed or disproved, and what the most useful next step is.

From that conversation a structured recap should emerge. The recap is stored and extends the working model the agent holds of my current situation. Next time, it should not start from zero. It should be able to continue – with goals, open questions, earlier decisions and recurring patterns.

What an AI Growth Agent should do for me

The agent is meant to accompany my private and professional development over time. It should know my starting point, understand my goals, and follow my activities and decisions. It should run regular reflection conversations, test my knowledge and competence, recognise progress and recurring blockers, and make connections visible across longer periods. Above all, it should be able to push back as a critical sparring partner – not for the sake of contradiction, but when my assumptions, priorities or excuses do not add up.

I am not trying to build a perfect single source of truth about my life. The system holds a structured working model of my reality. It contains only what the agent needs in order to support me usefully: goals, projects, activities, decisions, knowledge states, assessments, insights, obstacles, open tasks, next steps and changes over time. The model does not need to be complete. It needs to be useful, traceable and updatable.

Activity is not the same as competence

A central idea in this project is the distinction between activity and actual competence. Two hours of reading or completing a course module only prove that I engaged with material. They do not prove that I can explain it, apply it, or transfer it to a new situation.

So the system separates what I have done from what I can actually do. Activity might mean reading a chapter, watching a video, studying for an hour, working through a practice exam, or reviewing vocabulary. Competence looks different: explaining a concept correctly, mapping relationships, applying an idea, solving a practical problem, or transferring knowledge.

That is why the AI Growth Agent should be able to test me actively. It asks questions, analyses answers and updates knowledge state in a differentiated way – not merely as an arbitrary percentage. More useful is a distinction between recognition, independent explanation, application, transfer, and the confidence of the assessment.

Knowledge sources and personal documents

I want to connect scientific papers, articles, documentation, book chapters, notes and other learning materials. These documents should not just be archived. The agent should recognise content and structure, identify central themes, link the source to projects and learning goals, derive questions from the material, and assess me on the basis of that specific source. Knowledge gaps should be attributable to sections or topics, and later statements should be traceable back to the original source.

A typical exchange might be: I worked on this paper today. Please check whether I understood the central argument. The agent then asks comprehension, application and transfer questions. The results are linked to the document, the topic and my competence state. In that way the system stores not only that I learned something, but from what I learned it, which parts I understood, where my interpretation is still weak, and when the topic should be reassessed.

The technical model

Technically, I think of the AI Growth Agent as the overarching intelligent layer – the coaching experience and the orchestration. Behind it sits a central entry layer. That layer knows my projects, goals, current situation, relevant recaps, knowledge states and available specialised services. It also knows which capabilities each project requires.

Alongside or behind that entry layer, specialised services can exist: a Language MCP for vocabulary and language learning, a Learning MCP for assessments and spaced review planning, a Document Service for papers and knowledge documents, a Calendar Service for planned reviews, and later perhaps a Fitness Service or other domains. The central layer decides, based on the required capability, which service to call.

Why MCP matters – and why it is not the agent

In this picture, MCP – the Model Context Protocol – is not the agent. MCP is a standardised connection layer between the AI application and external data or functions. One way to put it: the AI Growth Agent is the sparring partner. MCP forms part of its nervous system. More plainly: the Growth Agent uses an MCP-based tool architecture to access specialised data sources and functions.

Routing should happen through capabilities. A project describes the capabilities it needs. A connected service describes the capabilities it provides. A project such as learning Spanish might need vocabulary_management, vocabulary_testing, spaced_repetition and language_progress. A Language MCP can provide those capabilities, perhaps along with grammar_assessment or similar functions. The central routing logic finds the matching provider and calls it.

That is more flexible than hard-wiring specific server names to projects. A service can later be replaced as long as the new one offers the same capability. I do not want to have to select multiple MCP servers manually in chat and decide myself which one a request needs. The entry layer is an orchestration or gateway concept – not a claim that MCP servers must be chained one after another.

The current gap between Voice and MCP

The desired end state is clear. I start a voice conversation. During the conversation the agent independently retrieves current project data, checks claims against stored information, uses specialised MCP services when needed, and writes the structured recap back at the end. That end-to-end flow does not yet work the way I want in the ChatGPT Voice experience I am currently using.

At the time of this experiment, I can either work with the connected MCP application in ChatGPT or use the Voice experience I want – but not yet combine both seamlessly. According to the current OpenAI help documentation on ChatGPT Voice, Live Voice does not initially support connected apps. The decisive gap is currently not in the data model, but at the interface between Voice and the connected tools. That is a time-bound platform state, not a permanent technical impossibility. A custom implementation via the Realtime API would be conceivable, but it would be a separate and potentially more costly project, and it is not part of my current prototype.

My current workaround

Until Voice can access the required tools directly, I use a manual bridge process. Before the voice conversation, the Growth System generates a compact project briefing: starting situation, active goal, current project state, recent relevant activities, known strengths, open knowledge gaps, active hypotheses, unresolved blockers, open tasks and the aim of the coming session. I paste that briefing into the chat context before we begin.

During the conversation I can speak freely. The AI knows the previously loaded project state, but it cannot freely pull new information from my MCP systems or write back directly. After the conversation, a structured recap is created. I hand that recap back to the Growth System, where activities, insights, competence states, decisions, action items, plans for the next day and possible goal changes are updated.

The process is not fully automated yet. But it already makes it possible to investigate the actual research question: does coaching become better through structured long-term memory?

The manual process is part of the experiment

I do not want to frame this limitation only as a downside. The intermediate step forces me to define clearly which information the agent really needs. That raises the more important questions: How much context is enough? What must be stored permanently, and what is only situational conversation? Which statements are facts, and which are interpretations? How do you prevent incorrect assessments from being carried forward indefinitely? How much past context improves coaching – and when does additional context become ballast? Which changes may the AI make on its own, and what should I confirm before it is stored?

These questions matter more for a genuine long-term AI sparring partner than simply collecting as much data as possible. Technical access to my past is not proof that the AI truly understands my situation.

What I really want to test

1. Does long-term context actually produce better conversations – or does the AI only seem more convincing because it repeats earlier terms and goals?
2. Can it recognise real patterns, for example that I regularly plan similar initiatives and then stall at the same point?
3. Can it push back constructively, test assumptions and ask uncomfortable questions instead of confirming every idea?
4. Can it distinguish activity from progress? Busywork is not the same as development.
5. Can it assess my knowledge realistically – not only recall of terms, but explanation, application and transfer?
6. How does a goal change over the course of the process? A good coaching system must not cling blindly to a goal once stated if new insights challenge the timeframe or the strategy.
7. How much structure does a personal AI agent actually need? Are good recaps and project documents enough, or does it require a detailed data model with assessments, topics, activities and historical states?
8. When does an assistant become an agent? Not every application with an LLM and a few tools is automatically autonomous. My system begins deliberately as a steered AI sparring partner with memory and tool access. It becomes more agentic where the system independently selects relevant information, calls the right tools, synthesises results, updates state, derives next steps and works consistently towards a goal across sessions. For important changes, control should still remain with me.

Risks and open questions

This experiment should not sound like product marketing, and it carries real risks. The AI can invent false patterns. Convincing phrasing is not evidence of a correct analysis. Self-assessments can be inaccurate, and automatically generated competence scores can appear more objective than they are. Outdated or wrong context can distort later conversations. Personal development data is sensitive. An agent must not become an uncritical authority over personal decisions. Too much structure can erase spontaneous development and nuance. MCP solves connection to data and tools, but not automatically the quality of coaching. Memory does not make an AI wise.

Looking ahead

The system is under construction. Architecture is a means, not the end. What matters is not how elegantly capabilities are routed, but whether conversations and decisions become demonstrably better over time. In later posts I want to document concrete experiences, failures and results – without claiming in advance that the experiment will succeed.

Perhaps this will become a genuine personal sparring partner. Or perhaps I am only building a very elaborate database that tells me, in friendly language, what I already know. That is exactly what I want to find out.