Will ChenA language for AI applicationsThe September and October 2025 work on domain languages, XJSN, and an interface for agents to read and change business objects.
Building Idyllic - Prior Iterations
September-October 2025
In September 2025, I wanted someone designing a delivery route or a pricing rule to work with AI as directly as a programmer could work with a coding assistant. They should be able to inspect the relevant objects, describe a change, and see the result in terms they understood. Building a new application around every idea introduced a large amount of unrelated work: database tables, API calls, screens, and the connections between them.
The earlier Idyllic builders had let me assemble prompts, workflows, and tools. I was now concentrating on the representation underneath those interfaces. A route has stops and constraints. A customer has records and relationships. A price-monitoring process has observations and rules for reacting to them. I wanted those concepts to exist as things an agent could read and manipulate directly.
A language for the domain
I called this domain encoding. The job was to define the vocabulary of a particular activity, together with the operations and rules that made sense within it. The implementation behind an operation could still make database calls. The person and the agent would work with the domain concept that those calls represented.
This slide came from the September pitch-deck work. DSLKit and XJSN Schema sit between a business and its representation as code. The comparison on the right is unfinished, but the intended division is visible: Idyllic would supply the language tools, and each application would supply its own concepts.
A domain-specific language is a language with a limited job. It does not need to express every program a computer can run. It needs to express the valid structures and operations of the activity it serves. That limit was useful here because I wanted to check an agent's proposed changes before carrying them out.
I had been implementing and testing XJSN, short for Extensible JavaScript Notation, as a common notation for those languages. It combined JSON values with function-call syntax. The calls were inert: parsing a document produced a tree of data, and validation checked that tree against the functions and argument types allowed by the domain. A call's appearance as code did not give it permission to execute arbitrary JavaScript.
This let me separate two decisions. The notation determined how a model wrote a structured expression. A schema determined what that expression was allowed to mean. Different applications could use the same parser while offering different operations. I describe the parser, schema, and validation loop in the XJSN article.
My working hypothesis was that a constrained vocabulary could make a model more reliable at a particular job. The September language experiments encouraged that direction. They did not establish that an entire business could be encoded automatically, or that a model would understand a domain merely because its output passed a validator. Choosing useful concepts and checking the quality of the work were still separate problems.
Defining the agent's behavior
The second stage was intelligence design: deciding how an agent should operate within the language. A schema could make a route valid without making it a good route. An agent still needed the relevant context, examples, and a procedure for deciding what to do. In the September plan, this was where workflows and agent behavior belonged. The domain representation gave that behavior something definite to act on.
The slide makes a broad claim that the problem becomes a coding-agent problem. What I was trying to carry across was a useful property of coding environments: a model can inspect a structured artifact, change part of it, and receive specific feedback about what is wrong. I wanted a similar interaction for work whose natural objects were routes, customers, or business procedures.
An interface for the encoded system
The third stage in the plan was deployment. Once the domain and the agent's behavior were defined, I wanted to expose them through an editor, a mobile application, or an API. That part of the September deck described the intended product. The integration path was still being worked out.
By October, I was exploring a dashboard of widgets as an interface to the same idea. A widget would hold useful state, provide information to the AI, and update when the AI changed it. A board of those widgets could make the configured system visible while also being available through an API. I wanted the interface both to operate the system and to test whether the underlying representation worked.
An equipment-support example made the interface questions concrete. Before opening a conversation, a person could select the piece of equipment they needed help with. That selection could supply known information to the assistant instead of making the person retype it into a prompt. We discussed rough wireframes to work through that experience. The source of the equipment data, the administrator's view, and the customer-facing interface still needed separate decisions.
The domain language specified what the agent could work with, but it did not decide how a person should encounter those objects. The October work brought those questions together: which information should already be present, which action should be available first, and what change should become visible when the agent acts. Those requirements carried into the next iteration, where I began testing the application model directly in code.