--- title: Capcom description: "Capcom is the internal operating environment we are building for Thinking Cap. We refer to it as our Company OS because its purpose is to provide a common layer across the people, AI models, software services,…" created: 2026-09-14 updated: 2026-09-21 authors: ThinkingCap R&D topics: [CapCom] status: published canonical: https://console.thinkingcap.com/rd/CapCom/Capcom_-The-Thinking-Cap-Company-OS date: 2026-09-14 --- # Capcom Capcom is the internal operating environment we are building for Thinking Cap. We refer to it as our **Company OS** because its purpose is to provide a common layer across the people, AI models, software services, knowledge and workflows involved in operating the company. It is explicitly an **AI-human system**. Our objective is not to progressively remove people from the company. We want AI and conventional software to do the work they are good at while preserving deliberate human gates where judgment, responsibility and quality matter. All software deployments, for example, remain human-gated. AI can investigate a problem, propose a solution, write code, run tests, review evidence and prepare a deployment. A person decides whether that change reaches production. We apply the same principle throughout Capcom. Automation can dramatically increase the amount of work a small team can accomplish, but increased output is useful only if the operating system surrounding it maintains or improves quality. ## A common operating environment Like most software companies, Thinking Cap has accumulated many systems over time. Source code lives in repositories, customer conversations arrive through email and support systems, infrastructure produces monitoring data, documentation describes parts of the product, and employees carry considerable operational knowledge. Capcom provides a common environment across these systems. The objective is not to reproduce every application inside one large application. Source control can remain source control, email can remain email, and specialized systems can continue doing the jobs they are good at. Capcom connects the work occurring within them. An incoming email, support request, code change, monitoring event or conversation can become information that the system understands and, where appropriate, acts upon. ## AI and humans in the same workflow We don't think of AI work and human work as separate processes. They are stages within the same workflows. A person may describe a problem. AI can investigate it. Deterministic software can gather evidence. AI can propose a change. Automated systems can test it. Another AI may review it. A human can inspect the evidence, question the reasoning and approve or reject the result. The workflow determines where each is appropriate. This is particularly important in software development. Capcom can allow AI to move surprisingly far through an engineering task without giving it unilateral authority to change production. The human gate is intentional. We are interested in increasing the amount of useful work that reaches that gate while also increasing the quality of the evidence available to the person making the decision. ## Reinforcing quality through workflow One of the important ideas behind Capcom is that workflows should become better as the system learns how work is actually performed. When something goes wrong, the lesson should not live only in someone's memory. If a reviewer repeatedly catches the same class of problem, we should ask whether that check can become part of the workflow. If a deployment requires a particular piece of evidence before a person is comfortable approving it, perhaps future deployments should produce that evidence automatically. If an AI makes a poor assumption, we should be able to identify where that assumption entered the process and improve the surrounding instructions, capabilities, tests or gates. Over time, these lessons can reinforce the workflow itself. This is different from simply asking an AI to "do better next time." We want improvements to become part of the system around the AI. Quality becomes something the workflow produces deliberately rather than something we hope emerges from a sufficiently capable model. ## Messages and intent One area of current work is understanding incoming messages. Natural language is useful as an interface because people should be able to describe what they want without first learning the structure of the software underneath it. However, we do not want natural language itself to become our internal operating model. When a message arrives, Capcom attempts to determine the intent behind it and translate that into a structured representation. A single message may contain several requests. It may be missing required information, refer to previous context or require permissions the sender does not have. Conceptually, the process looks something like: **Message → Intent → Capabilities → Jobs → Evidence → Human/Automated Gates → Result** Language models are particularly useful where human language, ambiguity and reasoning are involved. Between those points, we prefer deterministic software wherever practical. ## Capabilities and jobs Capcom is being built around discrete capabilities. A capability might search, match records, count results, generate a report, retrieve information, test software, communicate with another system or perform another defined operation. Each capability has requirements. It expects particular inputs, produces particular outputs and operates within defined permissions. Rather than asking a model to invent a process every time, we want it to determine which capabilities are required and whether they actually exist. If the requested operation requires something Capcom cannot currently do, the correct response is to identify the missing capability rather than allow a model to improvise one. These capabilities are assembled into jobs and workflows. This gives different parts of Capcom a common way of requesting, executing, reviewing and tracking work. ## The message envelope A message is more than its text. There is a sender, identity, conversation, intent, permissions, model context, tools, jobs, evidence, telemetry and history associated with it. We refer to this surrounding structure as the **message envelope**. We are experimenting with measuring and recording this envelope turn by turn. This gives us a much richer view of an AI-mediated interaction than simply retaining the original question and final answer. We can examine what the system believed someone was asking, which capabilities were selected, which tools were used, what evidence was gathered, where AI reasoning was involved and where a human decision was required. This observability becomes increasingly important as Capcom is trusted with more work. ## Tapestry and company knowledge Capcom also needs an evolving understanding of the company and its capabilities. This is the role of **Tapestry**, another part of our R&D work. Tapestry examines sources such as repositories and documentation to build a continuously evolving map of our software and its capabilities. We are extending that idea to other sources of company knowledge as well. A useful company knowledge system cannot depend entirely on people remembering to update documentation whenever something changes. Code changes, conversations, support activity, reviews and decisions all contain potential signals about how the company and product actually work. We are exploring how those signals can update our understanding while preserving evidence about where that knowledge came from. ## Attention Another part of Capcom is the **Attention** system. We don't want AI to create an even larger notification problem. An event should reach a person because that person needs to know something, make a judgment or take an action, not simply because something happened. An incoming email might be answered automatically. Another might update company knowledge. Another might create a job. Another might be handled entirely by an existing workflow. Something uncertain, consequential or requiring judgment can instead be brought to a person's Attention page with the relevant context and evidence already assembled. The goal is not to keep humans involved in every mechanical step. It is to involve them deliberately at the points where they add value. ## Human gates As Capcom becomes more capable, we think explicit human gates become more important rather than less. Not every operation needs one. Generating a report and deploying software have very different consequences. The workflow should reflect that difference. For consequential operations, the system can perform substantial work before the gate. It can investigate, prepare, test, compare and assemble evidence. But passing the gate requires a person. Software deployment is our clearest example. **There are no autonomous deployments in Capcom.** The AI can bring the change to the door. A human opens it. ## Why we call it a Company OS Capcom is gradually becoming the common operating layer between otherwise independent parts of Thinking Cap. It observes activity, interprets requests, invokes capabilities, coordinates jobs, gathers evidence, involves people when required and records what happened. The longer-term research question is what a company looks like when people, deterministic software and AI models participate in the same continuously improving operating environment. We are not trying to build an autonomous company. We are trying to build a company in which AI and humans can accomplish substantially more together, while making the processes surrounding that work more observable, repeatable and increasingly resistant to mistakes. The measure of Capcom is therefore not how often we can remove a human. It is whether each iteration of the system helps us do better work.