Overview

Since ChatGPT, AI has rapidly become mainstream. Initially, it was accepted as a tool that answers questions, refines sentences, and suggests code. However, the changes happening within enterprises are much greater than that.

AI is now moving beyond a simple answering tool to become a new intelligence that reads data, understands context, assists in decision-making, and participates in actual executionWithin enterprises, it is no longer only humans who work. Another intelligence that works alongside humans has emerged.

The core of this change is not "how to use AI well." The more important question is this:

What kind of operational system must an enterprise have for this new intelligence to work in actual tasks?

I define this operational system as AI Work OS.

AI Work OS is the foundation that enables AI to work within an enterprise by understanding, executing, and being controlled. It is a system equipped with data and context that AI can understand, an execution structure to perform actual tasks, and a control structure to safely operate that execution.

Presentation Materials

The presentation materials on which this article is based can be found at OpenAI Founder Day - AI Work OS (PDF).

The Emergence of a New Intelligence

Until now, enterprise work systems have been designed around humans.

Humans logged into systems, looked up data, wrote documents, submitted approvals, requested permissions, and took responsibility for execution results. Access control and auditing were also fundamentally built around human accounts, human permissions, and human actions.

However, when AI Agents enter enterprise workflows, this premise changes.

AI does not simply answer user questions; it performs the following tasks:

• Finds necessary data across multiple systems.

• Reads documents, conversations, policies, and past histories together.

• Organizes the evidence needed for decision-making.

• Creates deliverables such as reports, quotes, and analysis documents.

• Creates workflows that lead to approval requests or task execution.

At this stage, AI does not work like an independent employee, but it clearly becomes an intelligence that performs part of the enterprise's work. Therefore, enterprises cannot view AI merely as a simple SaaS tool or chatbot. They must see it as a structure where a new intelligence accesses enterprise data and systems and participates in execution.

The Emergence of Thinking Tools and Enterprise Questions on Operations and Control

Why AI Work OS is Needed

To work with this new intelligence, enterprises need three things.

First, Data and context that AI can understand.

Enterprise data is mostly scattered. It exists divided across databases, SaaS, files, documents, messengers, approval systems, work histories, and the tacit knowledge of those in charge. For AI to make meaningful decisions, simply accessing data is not enough. It must be able to understand in what work context the data was created, what policies and processes it is connected to, and what exceptions and domain knowledge it includes.

Second, An execution structure capable of performing actual tasks.

If AI remains at the stage of merely suggesting analysis results verbally, enterprise productivity will only increase marginally. Work must ultimately be executed. There must be a flow of looking up necessary data, calling systems, creating documents, sending approval requests to those in charge, and recording results. AI Agents must connect decision-making and tasks within this execution flow.

Third, A control structure to safely operate the execution.

The moment AI looks at data, calls systems, and gets involved in execution, the most important issue is not just performance. What becomes critical is what permissions it acted with, what it executed, who approved it, what records were left, and whether sensitive data was protected.

AI Work OS is a concept that ties these three elements into a single operational system. If context, execution, and control are separated, AI cannot delve deeply into work. Conversely, if all three are designed together, AI can work responsibly within the enterprise.

Context, Execution, and Control Structure of QueryPie AI Work OS

The Core Challenges are Execution and Control

When many enterprises talk about adopting AI, they first consider model performance, answer quality, and RAG accuracy. Of course, these are important. However, in an enterprise environment, the next problems are more difficult.

When AI goes as far as searching, analyzing, writing documents, requesting approvals, and executing, enterprises must answer the following questions:

• What data can AI access?

• What systems can it call?

• With what permissions does it execute?

• Is approval or review required before execution?

• Where are the execution process and results recorded?

• When a problem occurs, who takes responsibility and can track it?

If these questions cannot be answered, AI will remain in the laboratory and as a personal productivity tool. To enter the core operations of an enterprise, responsibility and control accompanying execution are absolutely necessary.

The core challenge of the AI era is not just making AI smarter. It is about making AI explainable: what it can do, what it should not do, and what it has done.

New Problems in the AI Agent Era: From Answer Generation to Task Execution

Three Axes Seen by QueryPie: AIP, ACP, FDE

QueryPie approaches AI Work OS through three axes.

The first axis is AIP(AI Platform). AIP is the execution foundation that actually makes AI work. It is a platform where enterprises can create AI Agents, configure workflows, and combine LLM, RAG, MCP, Skills, and Agents to experiment with and implement actual task execution.

The second axis is ACP(Access Control Platform)is. ACP is the foundation of control dealing with authorization, audit, and logging. It controls per resource what resources the AI accesses, with what permissions it calls the system, and how the process is logged and audited.

The third axis is FDE(Field Domain Engineering)is. FDE is the axis of application that understands the work at the customer site, structures domain knowledge, and transforms it into a form where AI can create actual performance.

These three cannot be seen merely as separate products or features. From the perspective of AI Work OS, AIP creates execution, ACP controls execution, and FDE ensures that execution connects to actual business value.

Enterprise AI Work OS composed of AIP, ACP, FDE

QueryPie's Evolution: From Access Control for Humans to Access Control for Intelligence

QueryPie was originally an access control company targeting humans, that is, human intelligence.

QueryPie's starting point was controlling and recording who, when, with what permissions, and what they did when a person accessed databases, servers, Kubernetes, and cloud resources.

However, as we enter an era where AI accesses enterprise data and systems, the scope of control has expanded. Now, not only humans but also AI is also a target of controlhas become.

To properly control AI, we must understand how it works. Simply "blocking access" is not enough. We need to know what context the AI sees, what tools it calls, in what order it makes decisions, and what execution it leads to.

That is why QueryPie created AIP. Through AIP, we experimented with how AI Agents move in actual work, and at customer sites, we accumulated experience on what domain knowledge and work structures are needed through FDE. And we are bringing this experience back to ACP to expand it into a structure that controls AI's access and execution.

This is the direction in which QueryPie evolves into an AI Work OS.

QueryPie Company Introduction and AI Work OS Expansion Flow

AIP: The Foundation of Execution

AIP is a playground where enterprises can build and run AI Agents.

Several elements are needed to create an AI Agent tailored to enterprise work. LLM handles judgment and language understanding. RAG searches internal enterprise documents and knowledge to provide the basis for answers. MCP provides a connection structure for AI to call external systems and tools. Skills define the procedures and abilities to perform specific tasks. Agent combines these elements to create a purposeful execution flow.

AIP: An Execution Platform Connecting Enterprise Work Systems with AI Agents

Structurally, the Agent makes judgments based on the LLM and calls enterprise resources such as DB, SaaS, internal systems, and APIs through the MCP Gateway. And this execution must take place under the control of ACP.

Structure controlling various LLMs and work tools centered around MCP Gateway

In other words, AIP is not a space where AI "thinks and answers," but a foundation where AI structures and verifies the execution flow of enterprise work.

Apps: The touchpoint that turns execution into work experience

While AIP is powerful, not all customers want to directly understand and combine MCP, Skills, RAG, and Agent.

What customers are curious about is not the technical structure itself. What they want to know is much more practical.

"How is it used in my work?"

That is why QueryPie is building work-unit Apps on top of AIP. Apps like Lingo, YuhoNavi, NotePie, and Outbound Agent are touchpoints that let users experience AI's execution capabilities within daily tasks such as meetings, financial analysis, document generation, and sales execution.

How AIP Apps connect to work automation experience

These Apps are not just simple demos. They are mechanisms that verify what user experience is needed when an AI Agent enters the starting point, results, approval flow, and logging structure of actual work.

In the AI Work OS, Apps are the layer that translates technology into the language of work.

Examples of AIP Apps executed in meetings, finance, knowledge, and sales tasks

Global customer and partner communication case using Lingo

FDE: Implementing Actual Value at Customer Sites

Enterprise customers do not want AI itself. What they want is effectiveness in their own work.

However, actual enterprise work is difficult to understand just by reading documents. There are undocumented exceptions, tacit knowledge of the person in charge, legacy work histories, and customer-specific conditions. Even the same term can have different meanings across departments, and even the same process can be operated differently in the field.

FDE plays the role of understanding this complex work, structuring domain knowledge, and transforming it into an executable form for AI.

The flow of FDE turning customer domains and data pipelines into executable prototypes

For example, in Payroll tasks, it was important to transform the exceptions and verification procedures of payroll calculations into a structure that AI could handle. In the Toyota case, we created a flow where AI could quickly make decisions from a task where people used to spend a long time interpreting complex specification branching. The Quotation Agent showed a direction of converting the tacit knowledge of experienced sales representatives into organizational execution assets. Financial automation transformed the task of writing competitor reports, which used to take nearly a month, into a structure that could be processed in minutes.

Payroll, Toyota T-Connect, AI Quote Agent, Financial Automation, and other FDE cases

The key here is not product installation. The key is whether actual work changes.

FDE is a crucial axis that ensures AI Work OS does not remain an abstract platform but translates into performance at the customer's site.

Ontology: The foundation for expanding individual productivity into organizational productivity

AI improving individual productivity and an entire organization working better are two different things.

Even if an individual quickly creates documents and performs analysis with AI, if the knowledge and context created in the process do not accumulate within the organization, productivity remains confined to the individual. To translate into organizational productivity, data, processes, policies, domain knowledge, and tacit knowledge must be interconnected.

This is where ontology comes in.

Ontology is a semantic map for AI to understand enterprise work. It structures what data is connected to what work, what policy restricts what execution, what role has what responsibility, and what exception leads to what judgment.

In AI Work OS, ontology is not just a simple knowledge graph. It is the foundation for expanding individual AI utilization into organizational productivity.

How ontology forms the semantic map of organizational work

Emergency Medical Case: Reasoning on Connected Context

Thinking about emergency medicine makes this principle clear.

If an emergency patient, ambulance, hospital, bed, medical staff, equipment, and travel route exist separately, what AI can do is limited. However, when this information is connected into a single context, AI can support actionable judgments.

Decisions such as which patient to send to which hospital, which beds and medical staff are available, what the travel route and time are, and whether the necessary equipment is ready do not come from a single piece of information. They come from a connected context.

Example of reasoning calculating beds, severity, and travel route together in an emergency medical context

This principle does not apply only to hospitals. In complex industries such as manufacturing, supply chain, aerospace, finance, and public services, important decisions come from connected contexts, not single data points.

AI Work OS is a structure that enables AI to judge and execute based on these connected contexts.

ACP: The foundation for controlling intelligence

When AI looks at various data, calls systems, and gets involved in execution, human-centric access control alone is insufficient.

Existing access control was designed around humans accessing systems. However, AI Agents call various resources on behalf of users, execute through multiple steps, and sometimes even perform approval requests or automated tasks.

Therefore, we must now also control the access and execution of this new intelligence called AI.

QueryPie ACP controlling AI Agent and work system access

ACP controls by resource what resources AI accesses, with what permissions it executes, and how the process is recorded and audited. All resources called by AI—databases, SaaS, APIs, internal systems, files, work tools—must be subject to permissions and auditing.

Enterprise Access Control expanding from databases to MCP

Control in the AI era is not simply a matter of allowing or blocking access. It is a matter of designing the context of execution, the scope of permissions, approval conditions, and recording and auditability together.

A platform equipped with product security, operational reliability, audit traceability, and compliance certification

Conclusion: The key to AI adoption is the operating system

The key to AI adoption is not simply using AI tools.

The key is connecting contexts so that the new intelligence can work, making it execute in actual work, and safely controlling that execution.

AI Work OS is an operating system that addresses all three of these together.

• AIP creates the execution foundation for AI to work.

• Apps turn execution capabilities into actual work experiences.

• FDE transforms the complex knowledge of the customer's site into an executable structure for AI.

• Ontology expands individual AI utilization into organizational productivity.

• ACP safely controls the access and execution of the new intelligence.

A new intelligence is entering the enterprise. What is needed now is not more AI tools, but an operating system where this intelligence can work responsibly.

That operating system is AI Work OS.