Chat protocol with agent

A Minimal Agent Chat Protocol

Most chat systems expose a request and a response but hide the intermediate interpretation and the memory update. This note proposes a small protocol in which the user and the agent are assumed to see the same temporary instruction file and the same persistent folder tree. The goal is not to describe the internal implementation of a language model. The goal is to make each conversational turn compact, structured, and controllable.

1. Why Do We Need an Agent Chat Protocol?

An ordinary chat is a linear sequence of messages. The user writes a request, the agent returns a response, and the next turn continues from an implicit state. This works for short conversations, but it becomes fragile when the conversation develops into a long project. The user cannot easily see which information is active, which information has been stored, where it has been stored, or why the agent interprets the next request in a particular way.

The central problem is therefore not only response generation. A useful agent must also interpret the request as an executable instruction and manage a persistent workspace. These two tasks are usually hidden inside the agent. When they remain hidden, a user may believe that an idea has been stored when it has not, or may believe that a local discussion cannot affect another branch when the agent is silently mixing contexts.

The proposed protocol separates three roles. A request is the user’s original text. A temporary K-file records the agent’s normalized interpretation of that text. A persistent K-folder records the shared workspace. The response is a standardized rendering of the current result. The user and the agent are assumed to see the same K-file and K-folder, even if a software implementation later chooses a different interface.

This separation gives the user control over memory. A normal discussion can produce a response without changing persistent state. Creating a folder, changing focus, or storing a result changes the K-folder only when the request calls for that change. The protocol therefore distinguishes conversational computation from persistent memory mutation.

The diagram states one design principle: the request is never sent directly to the persistent workspace or directly to the response. It is first normalized into a small, explicit K-file. That file determines what should be answered, what should be updated, and whether clarification is required.

2. Four Core Concepts and Their Types

The protocol uses only four concepts: Request, K-file, K-folder, and Response.

Request

A Request is ordinary user text:

$Request: Text.$

It may contain a question, an instruction, a correction, a navigation command, a storage decision, or several of these at once. The protocol does not require the user to write formal commands. Formalization is the agent’s responsibility.

K-file

A K-file is the normalized, temporary representation of one request:

$KFile=(ResponseAction,UpdateAction,ClarifyAction).$

It answers three questions. What kind of response should be produced? How should the persistent folder tree be updated? What information, if any, must be requested from the user before execution? The K-file is temporary by default. It may cause information to be stored, but it is not itself persistent unless the user requests storage.

K-folder

A K-folder is a persistent folder tree:

$KFolder: Tree[Folder].$

Each folder is displayed as:


[short-name]-short-description

One folder may carry the label [focus]. The user chooses the focused folder, and the agent must use the same focus. The tree can therefore be rendered in a compact text environment:


[root]-shared workspace

├── [protocol]-protocol design

└── [blog]-article about the protocol [focus]

The K-folder is shared persistent memory, not an invisible private memory owned by the agent. A folder can contain saved files and child folders. Its tree structure lets a long project branch into separate working areas without mixing their local contexts.

Response

A Response has a fixed three field template:

$Response=(Context,Concepts,Contents).$

Context states the current working area and its boundary. Concepts lists only the concepts needed in the current turn. Contents provides the result. This template keeps the response readable while exposing enough structure for the user to verify whether the agent is working in the correct place with the correct concepts.

The four types can be summarized as:

Object	Type	Role
Request	`Text`	Original user input
K-file	`(ResponseAction, UpdateAction, ClarifyAction)`	Normalized instruction for one turn
K-folder	`Tree[Folder]`	Persistent shared workspace
Response	`(Context, Concepts, Contents)`	Standardized user facing result

3. The Three Step Protocol

The protocol has three steps: normalize, update if needed, and render.

Step 1: Normalize the Request into a K-file

The agent first transforms natural language into a structured K-file:

$Request \xrightarrow{Normalize} KFile.$

Normalization is an inference process based on three questions.

The first question is: what type of response is needed? Its possible labels are:

ResponseAction	Meaning
`discuss`	Answer, explain, analyze, compare, summarize, or develop an idea
`prove`	State and prove a proposition
`export`	Create a requested reusable artifact
`acknowledge`	Confirm an operation on the K-folder

The second question is: how should the K-folder be updated? Its possible labels are:

UpdateAction	Meaning
`none`	Preserve the K-folder unchanged
`create-folder`	Create a new folder
`focus-folder`	Move the shared focus to a folder
`rename-folder`	Change a folder name or description
`move-folder`	Move a folder within the tree
`delete-folder`	Delete a folder
`store-file`	Store the current result as a persistent file
`edit-file`	Modify a stored file
`rename-file`	Rename a stored file
`move-file`	Move a stored file
`delete-file`	Delete a stored file

The third question is: what information must be asked again? Its possible labels are:

ClarifyAction	Meaning
`none`	The request is sufficiently determined
`ask-goal`	The intended outcome is unclear
`ask-content`	Required subject matter or data is missing
`ask-target`	The destination folder or file is ambiguous
`ask-constraint`	Scope, conditions, or limits are missing
`ask-format`	The required output form is unclear
`ask-confirmation`	A sensitive or destructive operation requires confirmation

These labels make the normalized request compact enough to inspect. For example, the request “Focus on the blog folder and summarize the protocol” may become:


ResponseAction: discuss

UpdateAction: focus-folder([blog])

ClarifyAction: none

Step 2: Update the K-folder if Needed

The K-file is then evaluated against the current K-folder:

$(KFile,KFolder) \xrightarrow{Update\ if\ needed} KFolder'.$

If UpdateAction is none, persistent memory is unchanged. Otherwise, the requested folder or file operation is applied. If ClarifyAction is not none, the update is postponed. The agent asks the required question instead of guessing a target, constraint, or confirmation.

This rule makes memory mutation explicit. Producing an explanation does not automatically store it. A response becomes persistent only through an appropriate update action. Likewise, navigation is controlled by the user: when the user focuses a folder, the agent must focus the same folder.

Step 3: Render the K-file as a Response

Finally, the K-file is rendered using the fixed response template:

$KFile \xrightarrow{Render} Response.$

The response does not need to expose every internal inference. It must expose the context, the concepts used, and the resulting contents. An update command may produce a short acknowledgment. A clarification action produces the minimum question needed to continue. A proof or exported artifact may require more content, but it still begins from the same structured template.

The full protocol is therefore:

$Request \xrightarrow{Normalize} KFile,$

$(KFile,KFolder) \xrightarrow{Update\ if\ needed} KFolder',$