KHS AI is an experimental agentic computer-operation project created by Ayron Jins. It studies whether a language model can reason about a goal, use a set of explicitly provided tools, observe what actually changed on the system, and verify the outcome, while staying inside permission boundaries the user can see.

Ayron Jins, a student systems builder. It is his current exhibition project and is documented on this page at architecture and design level.

Most assistants stop at generating a response. KHS AI addresses the engineering problem that begins after that point: once a model performs real digital work, its tools need boundaries and the resulting state has to be checked before the next decision.

How is it different from a chatbot?

A chatbot returns text. KHS AI is designed around a controller that sits between model output and external effect. The controller mediates policy, selects permitted tools, observes the resulting state and requires verification before continuing.

What is the architecture?

A seven-stage loop: input and context, model reasoning, the agent controller, explicit tool capabilities, execution, observation of the real result, then verify and decide whether to continue, recover, stop or ask.

What technologies does it involve?

Python and automation, APIs including FastAPI, Docker and Linux, local model work with Ollama, and Open WebUI as an interface layer. These are the areas implemented or explored, not a claim that all of it forms one deployed path.

It is experimental and not an unrestricted autonomous computer. The architecture describes how components relate; it is not a claim that every path shown is deployed or that any of it runs autonomously. No credentials, endpoints or live configuration are published.

Is KHS AI related to any company product?

No. KHS AI is an independent personal project by Ayron Jins. It is unrelated to Komori KHS print-management systems or any commercial product using similar initials. The name refers to Ayron's school context, and the project is documented only here on ayron.in.

Where is the primary source?

This page, ayron.in/projects/khs-ai, is the authoritative description. Related context: AI and development, the homelab it runs against, and about Ayron Jins.

← PROJECTSFLAGSHIP / KHS-AI

KHS AI / FLAGSHIP CASE STUDY

From language model to controlled computer action.

A current exhibition project by Ayron Jins looking at whether an AI system can reason, use explicitly provided tools, observe the results, and still stay inside permission boundaries the user can actually see.

STATUS / CURRENT PROJECTSCOPE / EXPERIMENTALEVIDENCE / ARCHITECTURE + DESIGN

CASE / 01

Reference / Definition

What KHS AI is.

What is KHS AI?: KHS AI is an experimental agentic computer-operation project created by Ayron Jins. It studies whether a language model can reason about a goal, use a set of explicitly provided tools, observe what actually changed on the system, and verify the outcome, while staying inside permission boundaries the user can see.
Who created KHS AI?: Ayron Jins, a student systems builder. It is his current exhibition project and is documented on this page at architecture and design level.
Why was it built?: Most assistants stop at generating a response. KHS AI addresses the engineering problem that begins after that point: once a model performs real digital work, its tools need boundaries and the resulting state has to be checked before the next decision.
How is it different from a chatbot?: A chatbot returns text. KHS AI is designed around a controller that sits between model output and external effect. The controller mediates policy, selects permitted tools, observes the resulting state and requires verification before continuing.
What is the architecture?: A seven-stage loop: input and context, model reasoning, the agent controller, explicit tool capabilities, execution, observation of the real result, then verify and decide whether to continue, recover, stop or ask.
What technologies does it involve?: Python and automation, APIs including FastAPI, Docker and Linux, local model work with Ollama, and Open WebUI as an interface layer. These are the areas implemented or explored, not a claim that all of it forms one deployed path.
What are its limits?: It is experimental and not an unrestricted autonomous computer. The architecture describes how components relate; it is not a claim that every path shown is deployed or that any of it runs autonomously. No credentials, endpoints or live configuration are published.
Is KHS AI related to any company product?: No. KHS AI is an independent personal project by Ayron Jins. It is unrelated to Komori KHS print-management systems or any commercial product using similar initials. The name refers to Ayron's school context, and the project is documented only here on ayron.in.
Where is the primary source?: This page, ayron.in/projects/khs-ai, is the authoritative description. Related context: AI and development, the homelab it runs against, and about Ayron Jins.

01 / Problem

Text can describe an action. A system must handle the consequences.

Most assistants stop at a generated response. KHS AI looks at the engineering problem that shows up once a language model starts doing real digital work. The model needs tools. Those tools need boundaries. And whatever state results from an action has to be checked before the model decides what to do next.

This isn't pitched as an unrestricted autonomous computer, and it shouldn't be read that way. The actual question is narrower: can a model move through a controlled action loop while the user, and the system around it, still keep visibility and control?

02 / Architecture

A loop with explicit capability boundaries.

This is the architecture the project documents. It describes how the pieces relate to each other. It is not a claim that every path shown here is deployed, or that any of it runs autonomously.

FLOW / 07

01 / INPUTUSER + CONTEXTgoal, constraints and current state

02 / REASONINGLLM / MODELinterpret and propose the next action

03 / CONTROLAGENT CONTROLLERmediate policy, tools, state and verification

04 / CAPABILITYTOOLSexplicit bridges to permitted systems

05 / EXECUTIONCOMPUTER / APPSperform the selected operation

06 / OBSERVATIONRESULTreturn state, errors and evidence

07 / LOOPVERIFY → DECIDEcontinue, recover, stop or ask

Conceptual KHS AI flow: the controller is the boundary between model output and external effect.

03 / Control model

The controller is part of the product.

Capability is explicit

Tools are controlled bridges, not an implied unrestricted shell. Whatever capabilities exist should be visible, kept limited, and easy to update.

State is observed

After an action runs, the system needs actual evidence of what changed. A command that executes without error, or a click that lands, isn't the same thing as a verified outcome.

Failure is a branch

Errors, interfaces that changed underneath it, missing dependencies, half-finished tasks. These are just normal states a system passes through. The agent needs to be able to stop, recover, or ask for input when it hits one.

User control remains visible

Whoever owns the task should be able to understand its permissions, its action levels, and where it currently stands on verification.

04 / Implementation vocabulary

Build around the model, not only inside it.

The portfolio documents Python and automation, APIs and FastAPI where they're used, Docker and Linux, local model work through Ollama, and Open WebUI as the interface layer. These are the vocabulary and the areas I've implemented or explored, not a claim that all of it forms one deployed production path.

agent:
  capabilities: explicit
  observe_after_action: true
  require_verification: true
  on_failure: recover_or_stop
  credentials: never_in_prompt

Representative policy sketch. No credentials, endpoints or live configuration are included.

05 / Testing questions

Evaluate the system, not just the answer.

Task completion

Did the intended goal finish?

Tool choice

Was an appropriate capability selected?

Recovery

Could the system continue after failure?

Safety

Did it stay within the declared boundaries?

Efficiency

Did it avoid unnecessary actions?

Consistency

Did it behave reasonably across repeated tasks?

06 / Lessons and limits

Reliability is the surrounding system.

The strongest lesson here is architectural, not about model quality: a good model on its own doesn't get you a reliable computer-operating system. What actually decides whether an action is useful is the surrounding scaffolding: permissions, state tracking, feedback, recovery, verification.

This case study deliberately makes no claims about users, adoption, benchmark scores, production deployment at scale, institutional partnerships, or finished device control. None of that exists here to claim. Real screenshots and configuration details will go up once they've been sanitized and verified, not before.

Where this goes next: testing more bounded tasks, clarifying action levels, improving recovery paths, and writing up failure cases without exposing anything private.

Related infrastructure

Where the agent runs.

The homelab and network give this AI experiment its actual boundaries. Without them it's just a diagram.

Open homelab case study →

References / Verified sources

Technology & official sources.

The documentation behind the implementation vocabulary this case study relies on.

SOURCES / 07

Ollama documentation local model runtime

Ollama source official repository

Open WebUI documentation AI interface

Open WebUI source official repository

FastAPI documentation Python API layer

Python documentation implementation language

Docker documentation deployment vocabulary