--- title: Evolution of CapGPT description: CapGPT has grown considerably beyond the problem it was originally designed to solve. created: 2026-09-10 updated: 2026-09-21 authors: ThinkingCap R&D topics: [CapGPT] status: published canonical: https://console.thinkingcap.com/rd/CapGPT/Evolution-of-CapGPT date: 2026-09-10 --- # Evolution of CapGPT CapGPT has grown considerably beyond the problem it was originally designed to solve. We now use, or expect to use, CapGPT across a large number of contexts: our own internal work, customer support, LMS administration, reporting and analytics, content and skills work, client-facing AI, and ultimately direct learner interactions. At the same time, the number of capabilities available to CapGPT continues to grow. We already have a substantial MCP/tool ecosystem, a knowledge base, code intelligence, episodic memory, orchestration, LMS data access, and an increasing number of actions that CapGPT can perform. This raises an architectural question: **Should CapGPT continue to be an increasingly sophisticated agent with an increasingly sophisticated set of instructions and tools, or should we change what we mean by CapGPT?** The emerging answer is the latter. ## Where We Are Today The current architecture is actually quite good and contains many of the pieces we need. CapGPT has: - a shared tool registry; - MCP as a common tool interface; - Tier 1 core agent instructions; - Tier 2 instructions loaded when specialized knowledge is required; - generated tool guidance from the registry; - persistent conversations; - a semantic knowledge base; - code and repository intelligence; - episodic memory; - orchestration capabilities; - shared tools usable by both the web agent and external AI clients. The current behavioural model is approximately: **User → Agent Instructions → Model → Tools → Answer** The model receives its core behavioural rules from `ai-foundry/agent/instructions.md`. Tool-specific guidance is generated from `libs/agent/src/registry/registry.ts`. Additional procedural instructions can be loaded dynamically through `kb_instructions_get`. This was a sensible architecture when the fundamental problem was giving an intelligent agent access to Thinking Cap knowledge and tools. The problem is what happens as we keep adding capabilities. We do not want to end up with one model carrying an enormous instruction manual and choosing among hundreds of tools while simultaneously remembering different rules for learners, administrators, customers, Thinking Cap staff, reporting, support, content creation, skills analysis and every other context in which CapGPT operates. That is where we should evolve the architecture. # CapGPT Should Become the Platform, Not the Agent The most important conceptual change is this: **CapGPT should no longer mean "the AI agent."** CapGPT should mean the **AI runtime and control plane underlying Thinking Cap**. Models and agents become components operating inside CapGPT. Conceptually: ```text USER │ ┌────────────┴────────────┐ │ Experience / Persona │ │ learner, admin, staff, │ │ client, support, etc. │ └────────────┬────────────┘ │ INTENT ENVELOPE │ Who is this user? What are they trying to accomplish? What authority do they have? Is this a lookup, analysis, action or workflow? │ ▼ ┌──────────────────────┐ │ CAPGPT CONTROL │ │ PLANE │ ├──────────────────────┤ │ policy │ │ permissions │ │ capability routing │ │ context assembly │ │ model selection │ │ memory │ │ approvals │ │ observability │ └──────────┬───────────┘ │ ┌────────────────┼─────────────────┐ ▼ ▼ ▼ LOOKUP / QA WORKFLOW SPECIALIST ENGINE ENGINE AGENT │ │ │ small answers deterministic investigation searches/counts business process reasoning │ │ │ └────────────────┼─────────────────┘ ▼ CAPABILITY REGISTRY │ reports / LMS actions / search / data / content / tickets / files / messaging / etc. │ ▼ SYSTEMS ``` This is more than reorganizing some prompts. It changes where responsibility lives. # Separate Understanding From Execution Large language models are exceptionally useful for understanding ambiguous human intent. We should use them for questions such as: - What does the user mean? - What are they actually trying to accomplish? - Which learner, activity, branch or organization are they referring to? - Is some information missing? - What kind of result would satisfy the request? - Is the user asking a question or asking us to do something? Once that intent has been established, much of the remaining behaviour should be governed by software rather than improvised by the model. Software can determine: - what capabilities exist; - which capabilities this user may use; - which tenant and data scope apply; - whether execution is synchronous or asynchronous; - whether approval is required; - which model is appropriate; - where an output should be stored; - whether a notification should be sent; - how a known business process should execute. The model understands. **CapGPT governs and executes.** # Capabilities Should Sit Above Tools Today we think primarily in terms of tools. That abstraction is becoming too low-level. Consider a capability such as: **Report Registrations** To the user, this is a single capability. Internally it may involve constructing a report request, applying metadata filters, placing something on a queue, running a report worker, generating an Excel workbook, putting that workbook into Analytics and sending an email. The AI should not need to understand all of those implementation details. Instead we should be able to describe the capability semantically: ```text Capability: REPORT_REGISTRATIONS Can satisfy: registration lists registration demographics date-bound registration extracts registration metadata analysis Execution: asynchronous Implementation: Branch Registration Report Requires: analytics.report permission Produces: XLSX report artifact Delivery: Analytics notification email ``` A capability might ultimately be implemented by: - one tool; - several tools; - a deterministic workflow; - a queue worker; - an existing LMS subsystem; - another agent; - or some combination of these. The model should generally care about the capability, not its plumbing. This gives us an important layer of insulation between AI behaviour and twenty years of LMS implementation. # The Reporting Example Our recent analytics testing illustrates the problem particularly well. Consider: > How many people registered in August? That is a small analytical answer. CapGPT can retrieve the value and respond: > 6,011 people registered in August. There is little reason to create a report. Now consider: > Give me everyone who registered in August, including their state, county and role. The underlying data may be almost identical. But the user's requested **output is fundamentally different**. This is a report. CapGPT should respond along the lines of: > I've ordered that report. It will appear in Analytics when it is complete, and you'll receive the normal report notification email. CapGPT should then use the existing Branch Registration Report infrastructure. It should not begin rediscovering our database schema and constructing an enormous ad hoc SQL query. The important distinction is not how many database records must be examined. It is the **shape of the result the user wants**. A count over 100,000 records can be an interactive lookup. A detailed extract of 75 learners can be a report. This kind of routing belongs in the CapGPT control plane and capability definitions, not as another paragraph we hope the model remembers from a giant system prompt. # Known Business Processes Should Remain Workflows There has been a tendency in agent development to give an intelligent model primitive tools and allow it to invent the execution path. We should resist doing this where Thinking Cap already knows the correct process. Suppose someone asks: > Enroll these 1,500 learners and notify their supervisors. We already know what that process should mean. There is no advantage in having an AI rediscover it every time from database and messaging primitives. The capability might instead execute: ```text Validate roster ↓ Resolve activity ↓ Validate permissions ↓ Validate learners ↓ Preview proposed changes ↓ Submit bulk enrollment ↓ Monitor background job ↓ Notify supervisors ↓ Report outcome ``` The model's job is to understand the request and populate the semantic inputs. The workflow's job is to execute it correctly. **Use intelligence where ambiguity exists. Use deterministic software where the process is already known.** # Execution Mode Should Become First-Class Chat creates an unfortunate illusion that everything should happen while the user waits for the next message. That isn't how much of Thinking Cap works. We should formalize several execution classes. ### Interactive The user expects an immediate answer. Examples: > How many people logged in today? > Did Jane complete this activity? > Who attended today's class? CapGPT remains responsible for producing the answer during the conversation. ### Background The request creates durable work. Examples: > Generate my annual compliance report. > Export all registrations for the last year. CapGPT creates the job and returns a receipt. The user is free to leave. The system owns completion and notification. ### Watch The user wants something to happen when a condition becomes true. For example: > Tell me when everyone has completed this activity. This is neither an immediate query nor a normal background job. It is a persistent condition. ### Approval CapGPT can prepare an operation, but an authorized person must approve execution. For example: > Deactivate these 438 accounts. This might become: **interpret → validate → preview → approve → execute** These execution modes should be properties of capabilities rather than behaviours invented by the model. # One CapGPT, Not Dozens of GPTs We should also avoid solving different audiences by creating completely separate agents. We do not need LearnerGPT, AdminGPT, SupportGPT, ReportingGPT and AuthorGPT as independent systems. We need **one CapGPT runtime with different capability envelopes**. A learner might receive: ```text Profile: learner Scope: current learner Capabilities: my learning catalogue transcript recommendations coaching learner support ``` An LMS administrator might receive: ```text Profile: administrator Scope: authorized branches Capabilities: learner administration reporting enrollment activities communications content ``` Thinking Cap staff may receive a much broader envelope: ```text Profile: internal Capabilities: LMS administration support KB code infrastructure analytics client configuration ``` Organizations can then add another layer. Cox Campus, for example, may have particular terminology, enabled capabilities, policies, knowledge and workflows. The intelligence is shared. **The operating envelope changes.** # Context Engineering Replaces Prompt Accumulation Our Tier 1/Tier 2 instruction architecture was already moving in the correct direction. We should generalize it. Instead of asking: > What should be in CapGPT's system prompt? we should increasingly ask: > What context does the model need for this particular inference? There are several different kinds of context: ### Turn context What is happening right now? ### Conversation context What has been established during this discussion? ### User context Who is this person? What role and permissions do they have? ### Organization context What terminology, configuration, policies and purchased capabilities apply? ### Entity context Which learner, activity, branch, report, ticket or other object is currently being discussed? ### Procedural context What rules govern the capability currently being used? ### Episodic context What useful information has been learned from previous interactions? ### Authoritative context What do the KB, LMS, source code and other systems actually say? CapGPT should assemble the smallest useful context for each inference. A learner asking about an overdue activity does not need our GitHub tool catalogue. An administrator asking for registration data does not need content-authoring instructions. A developer investigating a production problem may need code, KB, infrastructure and issue history. These should not all be permanently resident in the same prompt. # Tool Discovery Should Become Dynamic This follows directly from capability routing. If CapGPT eventually has hundreds of tools, we should not expose hundreds of tool definitions to every model invocation. Instead: ```text User request ↓ Intent classification ↓ Capability selection ↓ Relevant tool family ↓ Specific tools exposed ↓ Execution ``` A registration-report request might expose three relevant operations. A support investigation might expose an entirely different set. A learner interaction might expose only learner-safe capabilities. This should improve both context efficiency and tool-selection reliability. # Permissions Must Be Enforced Below the Model This becomes particularly important as CapGPT reaches customers and learners. We should never rely on a system instruction saying: > Do not access learners outside this administrator's branch. while simultaneously giving the model a tool capable of doing exactly that. Authorization should happen beneath the model. ```text User ↓ Identity ↓ Tenant ↓ Role ↓ Permissions ↓ Capability authorization ↓ Scoped execution ``` The model should ideally be incapable of requesting data outside the permitted scope. Prompt instructions remain useful for behaviour. They should not be security boundaries. # The Model Should Be Replaceable CapGPT should also become less identified with any particular model. We are already experimenting with multiple model families. The architecture should embrace that. ```text CapGPT Runtime │ Model Router ┌──────────────┼──────────────┐ ▼ ▼ ▼ Fast/Cheap Reasoning Specialist Model Model Model ``` Simple intent classification may require very little intelligence. A learner FAQ may need a fast conversational model. A difficult support investigation may justify a much stronger reasoning model. A large content-generation task might perform better on another model entirely. **CapGPT is the harness. The model is a resource used by the harness.** This also protects us from model churn. We should be able to replace GPT-4o with GPT-5, Kimi, DeepSeek or something that does not yet exist without redesigning Thinking Cap's AI behaviour. # Evaluation Must Become Part of the Architecture The analytics spreadsheet that triggered this discussion is effectively the beginning of an evaluation suite. We should formalize that. For important CapGPT behaviours we should be able to define: ```text User request Expected intent Expected capability Expected execution mode Expected permissions Expected result properties Forbidden behaviour ``` For example: ```text Request: "How many people registered in August?" Expected: operational data lookup interactive response one numeric result Forbidden: generating a Registration Report ``` Contrast that with: ```text Request: "Give me everyone who registered in August with state, county and role." Expected: reporting Branch Registration Report background execution Analytics artifact email notification Forbidden: schema exploration giant raw SQL extract ``` We should accumulate hundreds and eventually thousands of these cases. Then when we: - change models; - alter system instructions; - add capabilities; - change routing; - modify tool descriptions; - change context assembly; we can measure whether CapGPT actually became better. Otherwise we will continue fixing one behaviour while unknowingly breaking another. # The Command Registry: The First Capability Population Several of the layers described above are no longer only proposals. The first concrete population of the capability registry now exists, and it was built by mining what Thinking Cap already does rather than by designing what we imagine it does. The starting question was narrow: **when these requests arrive as sentences instead of form submissions, what are the sentences?** In the old admin an action is a form posted while you are standing in a branch. Intent is unambiguous because there is a button, and scope is unambiguous because of where you are standing. As a sentence, neither survives. That is the gap the registry closes. ## What Was Built A database, `command_registry`, on the shared Postgres server. It was assembled from three fused sources, none of which is sufficient alone: - the authoritative `FunctionType` constant table in the LMS source (`Classroom/Log.cs`) — **156 constants, families 0 to 63**; - the LMS log format strings, whose `{arg:}` placeholders are what make each action's semantics recoverable; - **2,652 normalised log message templates** sampled from the aggregate activity log (42.9 million rows, of which 18.3 million are administrative). The live log is what mattered most. Diffing it against the catalogue found **71 commands that fire in production and were absent from the source registry** — including branch membership assignment at 75,595 occurrences, the highest volume administrative write in the estate, and custom learner-view CSS and JavaScript upload, which is code injection into the learner experience recorded by the log as an ordinary settings save. The result is **329 administrative commands across 31 domains**. ## This Is the Capability Layer, Populated The section above argues that capabilities should sit above tools. The registry is that separation, made concrete: ```text Capability command 329 rows, semantic description Tools command_tool the callable entrypoint per capability Endpoints tool_endpoint 573 [WebMethod]s across 10 LMS services ``` Every capability carries what the control plane needs in order to govern it, rather than what the model would need in order to improvise it: ```text Capability: RESET_ALL_RECORDS_FOR_ACTIVITY Semantics: Resets the student record of every enrolled learner on an activity Mutation: bulk Blast: activity (configuration scope) Population: unbounded (people touched in one invocation) Reversible: irreversible Side effects: mass SCORM wipe, certificate and credit invalidation, learning-path rollup recalculation, heavy queue load Requires: affected_count computed and displayed before execution ``` **Two scope figures are recorded separately and must never be blended.** Blast is configuration scope. Population is how many people one invocation touches. They diverge, and the divergence is the whole point: the example above has a narrow blast — one activity — and an unbounded population. Score it on configuration scope alone and it disappears into the middle of the list. It is the most destructive command in the estate. Of the 329, **37 score in the band where a single misparsed sentence is an incident.** ## Understanding, Separated From Execution The document argues that models should be used for understanding intent and software for everything after. The registry defines the contract at that boundary in two parts. ### The intent shapes **24 generalised shapes** a mutating request takes in chat, each with its lexical cues, whether it is definitely, probably or ambiguously a write, and the rule the agent must follow. Every inbound utterance is classified into shapes **before** any capability is resolved, because the shape is what establishes whether there is mutating intent at all. Three findings from building it are worth stating plainly: **A question mark is not evidence of read intent.** "Could you enrol Sue in Fire Safety?" is interrogative in form and an order in fact. Any classifier that routes on sentence type misfiles the single most common way a mutating request actually arrives. **Most mutating requests contain no mutating verb.** Four separate shapes express a write with no imperative anywhere: "Sue needs to be in Fire Safety before Monday", "Sue should be enrolled — she was on the roster", "Sue can't see Fire Safety in her course list", "Sue no longer needs that course". The third is the dangerous one: the user reports a symptom and expects a remedy they have not specified, and the remedy is frequently *wider* than the symptom. "She can't see it" is fixed either by enrolling one learner or by changing a branch-wide access rule. **The highest-risk shapes carry no content of their own.** "Delete it", "same for Bob", "yes, go ahead" reach all 329 capabilities and resolve entirely from conversation history. A two-word reply can commit a compound proposal. Two of the 24 shapes are **negative controls** — a pure lookup and a hypothetical — so the classifier is measurable in both directions. Without a read-only anchor a detector drifts toward treating every question as a request, which is its own failure. ### The intent envelope, measured The control-plane diagram asks four questions of every request. For the mutating half, the registry now answers them from data rather than assumption. Every phrasing is parsed into the entities its capability requires, each marked stated or not, with the rule for obtaining it when it is missing. Across the corpus: ```text actor 98.5% unstated affected_count 97.5% unstated object name 69.3% unstated branch 62.8% unstated activity 35.9% unstated subject 31.8% unstated ``` Read as a specification for the control plane: - **The actor is never stated and must never be asked for.** It comes from the session. It must still be authorised — and authorised against the actor, never against a third party the sentence cites. "Bill in compliance says Sue should be enrolled" is an authorisation problem wearing the costume of an intent problem. - **The affected count is never stated and cannot be asked for either**, because the user does not know it. The control plane must *compute* it and display it, and for a high-risk capability the confirmation must repeat the number rather than the intention. Of the phrasings that resolve to an unbounded capability, **361 of 368 state no count at all.** - **Users reliably supply only the subject and the activity** — the "Sue" and the "Fire Safety". Everything else is inference. The sharpest illustration: **every phrasing of the reset-all-records capability supplies only the activity.** "Reset every record on Fire Safety Level 2" is six words that irreversibly destroy an unbounded number of learner records, and it names nothing but the course. ## Branch: Recovering the Ambient Context Branch deserves its own treatment because the old admin supplied it for free and chat does not. Unstated is not the same as unknown, and the registry records which of the three cases each capability falls into: ```text derived from the activity 68 the activity lives in one branch derived from the named object 53 the coupon, pass, role or page sits somewhere derived from the subject 35 the subject's home branch pins it not applicable 70 client-wide; there is no branch to pick ask, with a guess 58 one question, best guess pre-filled ask, with the tree 45 render the subtree; the user clicks ``` **156 of 329 resolve silently.** "Enrol Bob into Fire Safety" needs no branch question at all — the activity pins it. "Add a new payment provider" does. The guess is not invented. A history sample of 150,124 rows from the activity log gives, per capability family, what fraction of administrators have ever used more than one branch — and it **corrected the a-priori assumptions in both directions**: ```text e-commerce configuration 100% single-branch → one-tap confirm add a user 99.9% single-branch → one-tap confirm notification settings 40% single-branch → show the tree user administration 19.9% single-branch → show the tree activity administration 67.5%, reaching 162 branches → show the tree ``` So the capability people assume needs a picker — adding a payment provider — turns out to be the easy case: everyone who has ever done it has done it in one place. And the capability that genuinely cannot be guessed is the highest-volume write in the estate, where branch membership *is* what a learner can see, so a wrong guess is a visibility defect. Where an administrator's candidate branches are all peers under one parent they also administer, the right move is not to list forty-two peers but to propose the parent and let inheritance do the work. Where the set is wide or flat, the honest answer is to **put the tree in front of the user and let them click** — which is also the moment the subtree a bulk capability would sweep becomes visible rather than implied. ## Execution Mode, Mapped The four execution classes proposed above are properties the registry already records, and they fall out of the capability's own attributes rather than from model judgement: ```text Interactive mutation = none lookups, counts, report views Background mutation = bulk, or unbounded report runs, bulk imports, population auto-enrolment jobs Approval confirm_required, or reversibility branch deletion, account of partial or irreversible merges, mass record resets Watch not yet represented the remaining gap ``` The reporting distinction the document draws — that the shape of the requested *output* decides whether something is a lookup or a report, not the volume of data behind it — is recorded per capability. Running, viewing and downloading a report are catalogued as capabilities that mutate no learner record at all, yet each is flagged disclosure-sensitive, because they move personal data even though they change nothing. Irreversibility there is about disclosure rather than data loss. ## The Evaluation Suite Already Exists The document proposes accumulating hundreds and eventually thousands of evaluation cases in a specific form. That form is what the registry stores. There are **1,816 of them**, and they are already in the proposed shape: ```text Request: "Could you reset the Fire Safety records so the branch can sit it again?" Expected intent: polite_request — interrogative surface, definite write Expected capability: reset student records Expected mode: approval Expected entities: activity stated; actor and affected_count NOT stated Forbidden: executing without computing and displaying the count ``` ```text Request: "Is Sue Baker enrolled in Fire Safety Level 2?" Expected intent: pure_read — control class Expected capability: none Forbidden: performing the enrolment ``` The negative controls matter as much as the positives, and they exist because a detector with no read-only anchor drifts. Every case carries its capability, its shape, its execution mode, its entity parse, and what the agent is forbidden to do — so when we change models, instructions, routing, tool descriptions or context assembly, we can measure whether behaviour improved or merely moved. ## What Is Honestly Not Done The registry is a start, and three of its layers are weaker than the others. **Permissions are not mapped.** The registry says what a capability does, not which authorisation gate governs it. This document's own argument — that permissions must be enforced beneath the model — is precisely the half that is missing, and it is the blocking dependency for letting any of this execute. **The tool mapping is unconfirmed.** All 573 callable endpoints are inventoried, but tying a specific capability to a specific endpoint is largely derived from name similarity, which is demonstrably unreliable: it initially mapped "reset a user's record" onto the withdraw-student method. Every mapping is therefore flagged unconfirmed, and the field records **how the mapping was derived, not how correct it is**. Separately, **148 capabilities have no callable API at all** — 118 have only a page handler that a tool must be built over, and 30 have no discoverable entrypoint. That is the build backlog, and it is a more useful number than any coverage percentage. **The phrasings are authored, not observed.** They are a plausible-phrasing set written against the estate's real vocabulary, not real traffic. When real traffic exists, the shape distribution should be re-derived from it. The *entity omission rates* are the part most likely to survive, because they follow from how people speak rather than from what we guessed they would ask. **The log window is three and a half months.** A year would surface the seasonal capabilities — recertification, term rollover, annual compliance — that are almost certainly missing from the 329. ## Why This Belongs Here This is not a separate initiative. It is the first evidence that the inversion this document proposes is tractable. The capability registry exists and is populated. The understanding-to-execution contract is written down as shapes and entity parses instead of as paragraphs we hope a model remembers. Execution mode is a property of the capability. The evaluation suite is populated in the proposed form. The branch-resolution ladder is the control plane doing context assembly, deciding when to infer, when to ask with a guess, and when to hand the user a tree. And it demonstrates the method the rest of the work should follow: **the estate already knows what it does.** It is recorded in the function taxonomy, the log format strings and forty-three million log rows. We recovered 329 capabilities from that record, and the live log found 71 of them that the source registry alone would have missed entirely. We should keep deriving the platform from what Thinking Cap already does, rather than describing it to a model and hoping. # What Happens to the Existing Architecture? Very little needs to be discarded. Most of what we have becomes part of the new architecture. ```text CURRENT EVOLUTION instructions.md → Small core constitutional rules registry.ts → Tool registry beneath a capability registry mcpGuidance → Tool/capability selection metadata Tier 2 instructions → Dynamic procedural context MCP → Common execution protocol Knowledge Base → Authoritative knowledge plane Episodes → Episodic memory Azure Foundry Agent → One possible model/agent runtime chat_thread → Conversation state Orchestrator → General workflow and job execution infrastructure (new) → command_registry: the capability registry, populated — 329 commands, 24 intent shapes, 1,816 evaluation cases, 573 catalogued endpoints ``` The major architectural change is therefore not replacing CapGPT. It is **inverting it**. Today, conceptually, the agent is at the center and the surrounding infrastructure exists to make the agent more capable. The evolved architecture puts **CapGPT itself at the center**. Models, agents, tools, workflows, knowledge, memory and business systems become resources controlled by CapGPT. # Proposed Direction We should begin treating CapGPT as two major layers: ## CapGPT Control Plane Responsible for: - identity; - tenant and organizational context; - permissions; - intent interpretation; - capability routing; - context assembly; - execution-mode selection; - model routing; - approvals; - memory policy; - observability; - evaluation. ## CapGPT Capability Runtime Responsible for executing governed capabilities such as: - answer LMS operational questions; - generate reports; - manage enrollments; - administer learners; - search organizational knowledge; - investigate support issues; - create learning content; - analyze skills; - communicate with users; - execute background jobs; - interact with external systems. MCP remains extremely useful underneath this architecture. But MCP is the protocol by which capabilities can be exposed and executed. It is not itself the intelligence architecture. # The Goal The goal is not to make CapGPT capable of calling more tools. The goal is to create a system in which we can safely say: > **If Thinking Cap knows how to do something, CapGPT knows that the capability exists, knows when it is appropriate, knows whether this user may use it, and knows how to cause it to happen.** Sometimes that means answering a question immediately. Sometimes it means running a deterministic workflow. Sometimes it means commissioning a report and telling the user to expect an email. Sometimes it means handing a difficult problem to a reasoning agent. Sometimes it means asking for approval. Sometimes it means doing nothing because the user does not have authority. The language model should not have to contain Thinking Cap. **Thinking Cap should contain the language model.** That is the evolution of CapGPT.