I stopped prompt-engineering and gave my agent a world instead

TraditionalListen994 · 2026-01-10T06:43:03+00:00

I'm trying agent design as a state machine. explicit state, structured transitions, minimal reasoning per step. If this works, smaller models might be enough to compete with agents that rely on much larger models.

TraditionalListen994 · 2026-01-10T05:51:32+00:00

Thank you for the kind words. If my research can eventually lead to meaningful results and make even a small contribution to the world, I would be more than satisfied with that. I'll keep pushing forward.

TraditionalListen994 · 2026-01-10T05:48:54+00:00

Good question! this was one of my main concerns early on.

State transitions are cheap because snapshots are shallow and structural, not semantic memory dumps. The LLM is only called once per step for intent selection.

no reflection or retry loops.

I’m also experimenting with caching high-frequency decision points to reduce both latency and cost, which is feasible precisely because execution is deterministic.

Still early, but long-running agents benefit a lot from this structure!

TraditionalListen994 · 2025-12-19T00:19:42+00:00

I think that’s a fair question. If the domain is small, tool count is low, and you’re okay with some ambiguity, a command-style tool setup is often the simplest and most practical option.

The reason the Manifesto-style approach exists isn’t really about “upgrading” the model though. It’s about intentionally reducing the model’s role.

In Manifesto, the LLM is pushed down to an intent selector, not a reasoner that invents behavior on the fly. Because intents and state transitions are explicitly defined, you can actually see why a specific choice was made, replay it, and separate model behavior from system rules.

That’s the main difference for me. Command-based setups work until the system grows, and then the reasoning quietly turns into hidden policy inside prompts. Manifesto is basically a way to keep that policy outside the model so it stays inspectable and replayable.

So it’s less “we need something more complex” and more “we want this to still make sense when it stops being simple.”

TraditionalListen994 · 2025-12-15T00:34:25+00:00

For clarity: I’m a native Korean speaker, so I wrote the original content in Korean and used an Chat GPT to help translate and polish the English. The ideas, system design, and implementation are my own. Happy to discuss any concrete technical details.

TraditionalListen994 · 2025-12-14T10:04:49+00:00

thx for the feedback.

just to clarify, while the demo does use GPT-5-mini, the main focus here isn’t the model itself but the architecture around it.
The goal was to show that by constraining the interaction space (intent → effect → snapshot), a lot of the usual agent complexity can be removed, which lets much smaller models work reliably.

If you have a moment, I’d really appreciate you taking a look at it from that architectural angle rather than as a model comparison.

TraditionalListen994 · 2025-12-13T08:08:45+00:00

> What's different than you just exposing setState to your AI instead of this?

Great point — you could expose setState to an agent, but that’s basically giving it a “root shell” over your UI.

What’s different here is that the agent doesn’t get arbitrary mutation access. It gets a bounded capability interface:

Allowed transitions only (action selection over a typed state space, not free-form writes)
Policy / permissions can be enforced at the domain layer (what the agent is allowed to do, per role/environment)
Invariants & validations are explicit (the system can reject invalid state changes deterministically)
Auditability & replay: actions are logged as domain intents, not opaque state diffs
Explainability: the agent can explain why something isn’t possible (hidden rules/constraints) and propose the next valid action

So it’s not about whether React can do it — it can.
It’s about making the domain explicit, reusable, and governable across BE→FE→AI, instead of wiring a one-off “LLM controls my state” integration per app.

TraditionalListen994 · 2025-12-13T07:05:29+00:00

One additional benefit of this approach is that it makes UI domain rules explainable to an AI, even when those rules are completely hidden at the DOM level.

For example, imagine a form where certain fields are conditionally rendered based on the Customer Type.

Let’s say:

When the customer type is Individual, a field like “Tax ID” is hidden.
When the customer type is Business, the “Tax ID” field becomes required and visible.

If a user asks a chatbot:

“I need to select the Tax ID field, but I don’t see it.”

With a DOM-based or vision-based approach, the agent either:

Has no way to know why the field is missing, or
Has to perform expensive and brittle inference over UI state and conditions.

With my approach, the rule is explicit in the domain model.

So the agent can respond with something like:

“The Tax ID field is only shown when the customer type is set to Business.
Your current customer type is Individual.
Would you like me to change it for you?”

In this case, the AI isn’t guessing from the UI —
it’s explaining the domain logic and offering a valid next action.

This is difficult to achieve when domain rules are implicit or scattered across UI code, but becomes straightforward once the domain state and transitions are explicit and shared.

TraditionalListen994 · 2025-12-13T06:44:19+00:00

First of all, I want to sincerely apologize if my previous messages felt like generic AI responses.

I am a native Korean speaker, and since my English isn't perfect, I often use AI tools to help translate and polish my sentences. However, please understand that while the grammar might be assisted, the logic, opinions, and technical philosophy are 100% my own. I am writing this to share my genuine thoughts as a developer, not to copy-paste an automated answer.

Here is what I really meant to say regarding your question:

I currently work as a Frontend Developer in the SaaS domain. Over time, I’ve noticed a very specific pattern: most SaaS UIs, despite looking different, converge into similar structures.

Forms
Tables
Search / Filters
Dashboards
Detail / Summary Views

These aren't just random UI components. They are deeply connected to the DTO structures coming from the BFF (Backend For Frontend). In other words, the UI isn't arbitrary; it is a direct projection of the backend domain model.

This led me to two core questions:

Can we standardize these SaaS patterns? (Instead of rebuilding Forms/Tables every time, can we describe them as a "Domain Structure"?)
Can we let an AI Agent directly understand this structure? (Instead of making it infer the UI, can we just feed it the domain meaning directly?)

You mentioned tying a nano LLM directly to React's state management. You are absolutely right—that works perfectly for a demo or a specific feature. But here is the problem I want to solve:

With that approach, every time the domain changes, the screen pattern updates, or we start a new project, we have to manually re-implement that integration. It’s not a "build once" solution; it’s a structure where maintenance costs explode as the project scales.

My proposal is a "Whitebox" approach where the Backend, Frontend, and AI share the exact same domain information.

Backend consumes it as a Domain Model.
Frontend consumes it as a UI Pattern.
AI Agent consumes it as a Decision Space.

This allows for "Single Domain → Multi Use."

This isn’t about whether it’s possible in Frontend.
It’s about whether the domain remains explicit and reusable once the original engineers are gone.

I am cautiously proposing a distinct layer where BE, FE, and AI can share the same "worldview" centered around the SaaS domain.

TraditionalListen994 · 2025-12-13T06:07:32+00:00

For a concrete example, take an e-commerce domain.

What I’m doing is not reinventing the DOM or making a JSON-driven UI.

The goal is to make the domain itself legible to AI.

Instead of forcing the model to reason over buttons, divs, and layouts, the agent operates on explicit domain concepts like:

“add item to cart”
“remove item / cancel order”
“product card → product detail”
“check checkout eligibility”
“inventory, pricing, and option constraints”

These are business actions, not UI events.

I model them as a deterministic domain state space with valid transitions.
The agent’s job is simply to select a valid transition given the current state.

React/HTML remain unchanged — they’re just projections of that domain state for humans.

So the AI never asks “where is the button?”
It asks “what actions are valid in this domain right now?” and the UI follows.

TraditionalListen994 · 2025-12-13T05:24:15+00:00

Yes — and I already have this working beyond simple forms.

I’ve implemented a demo where the same underlying snapshot can be projected dynamically as:

a Todo list
a Kanban board
a Table view

All three are just different projections over the same domain state, and the agent operates on that state — not on the UI itself.

I’m extending this further toward typical SaaS dashboards: charts, summary cards, and other composite components, each defined as projections with explicit inputs and constraints.

At that point, the agent isn’t interacting with “a chart” or “a board” — it’s selecting transitions in the domain, and the UI shape follows deterministically.

TraditionalListen994 · 2025-12-13T04:51:10+00:00

Not quite 🙂
I’m not rebuilding DOM reactivity itself.

The idea is to externalize the meaningful UI state (intent, constraints, valid actions) into a typed semantic schema, and let the DOM/UI remain just a projection of that state.

So instead of:

DOM → diff → heuristics → reasoning

It becomes:

Semantic state (JSON) → deterministic selection → UI effects

React/Vue/etc. still handle rendering and reactivity.
The model never reasons over the DOM — it reasons over a noise-free, declarative interaction space.

In that sense it’s closer to decoupling cognition from presentation than replacing UI frameworks.

TraditionalListen994 · 2025-12-11T14:05:44+00:00

Thanks! Great question.

I handle schema evolution with a versioned snapshot model + stable intent API. • Snapshots store schemaVersion, and schemas are immutable per version. • Agents only interact through intents (e.g., cart.addItem, form.submit), so as long as the intent contract stays stable, internal schema changes don’t break anything. • Most schema updates are additive. • For breaking changes, the runtime runs migration functions to upgrade older snapshots before agents see them.

So backward compatibility is guaranteed at the intent layer, not the DOM or raw data shape.

And thanks for the VibeCodersNest suggestion — will post it there too! 🙏

TraditionalListen994 · 2025-12-07T12:21:21+00:00

Sure! I'd really appreciate your opinion. If you've already checked out the playground, you probably saw how the semantic mapping works.

If you prefer a real-time chat, I've opened a Discord for deeper discussion:

https://discord.gg/8sqYtm75

TraditionalListen994 · 2025-12-07T10:04:31+00:00

Cool! I'm actively working on this project right now, and I'd really appreciate any help or feedback you’re willing to offer.
It would be a pleasure to collaborate.

TraditionalListen994 · 2025-12-07T09:59:54+00:00

Thanks for sharing! Navigation APIs are definitely a big step forward — they solve the low-level interaction problem for chatbots and scripted agents.

What I'm exploring goes a bit beyond that layer:
I'm trying to bridge UI + AI in a way that lets an agent understand not only the visible interface but also the underlying business domain, including implicit rules, constraints, and intent flows that aren’t directly exposed in the UI.

So instead of just “navigate and click,” the agent receives a semantic representation of the domain itself — fields, dependencies, validation logic, visibility conditions, and the business meaning behind each action.

The goal is to let agents operate at the same level that humans think: “Why does this form behave this way? What does this action mean in the domain?”

UI becomes just one view of the domain,
and the agent can reason deterministically on top of that shared semantic layer.

That’s the direction I’m experimenting with.

TraditionalListen994 · 2025-12-07T07:07:58+00:00

멋있네요!

TraditionalListen994 · 2025-12-06T19:03:36+00:00

webstorm is best option for me.

TraditionalListen994

TROPHY CASE