אל"ש מסביר- מאיפה מגיע השם "סוכן", מה זה agentic computing - איך זה עובד ולמה זה יקר - והפתרון שלי

https://smartaccess.co.il/sa-architec... SmartAccess — A Technical Perspective Reading the platform through the lens of a prototype-based authoring language Thanks to LLMs, the cost of building a small app or website for a specific task has plummeted to near zero. We are on the verge of a tsunami of niche, hyper-specific software flooding the market. Trying to build a fixed product for one of those niches means stepping directly into that flood — and as Peter Thiel famously observed, “competition is for losers.” Building the “best” app is an impossible task anyway, because the “best” is different for everyone. Historically, users have had to adapt to the software, just as programmers had to adapt to the machine. In both cases, users are forced to conform to a developer’s specific worldview, hardcoded and imposed upon them. Software attempts to digitally map the world using abstractions, but reality is deeply subjective. As Alfred Korzybski famously stated, “A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.” Trying to build one universally accurate map of reality for every user will always fail in that goal (it does not mean that it will not be popular, or, good enough at the time). This led me to a question: how can we let users impose their own worldview onto a platform? How do we build something that molds to the user dynamically, even as their context changes throughout the day? Crucially, this 'architecture' wasn’t theorized top-down in a vacuum. It emerged organically through a rigorous development process of building the things that I, and other users, actually needed, while constantly wrestling with this exact problem. Our core engineering philosophy is strict: build only what is known to be necessary and actively used. Just as we refused to force users to adapt to rigid software, we refused to force the platform to fit a preconceived architectural design. The design evolved specifically to fit the reality of those needs. Instead of shipping a rigid product, we built a generative environment. By combining a conversational agent with a structured GUI, SmartAccess lets users generate their own highly specific tools using a prototype-based object model. Users can even customize their own UI, within defined boundaries. We know that when people actively build and personalize their environment, they form a strong psychological attachment to it — meaning this approach isn’t just about utility; it carries a massive retention advantage. But this isn’t just an isolated sandbox. Statistically, if one user needs a specific calculation or workflow, someone else will eventually need it too. Once a generated tool is created, it becomes available in the shared standard library. This creates a fundamental shift in how we manage inference compute for agentic workflows, optimizing the recurring inference cost that dominates agentic AI at scale. This represents just one of several groundbreaking methods we deploy to scale agentic AI. All they do is give a prompt, and a prompt runs in three steps: decipher the intent, generate the logic, and present it. Generation is the expensive, generative-AI step — so when a prompt’s deciphered intent matches a block that already exists, we run only the decipher, and generation and presentation collapse into simple information retrieval of a block already understood. Not every prompt becomes a block, though: sometimes the answer simply stays in the chat, and a result only becomes a block when it can actually be presented as one. This is the modern TDD as we see it. The user knows "what he wants" - his intent when he does the prompt. If he gets the result, then it worked. If it doesn't he "corrects it" (debugging), and then rerunning the test. This way we take advantage of user prompting behaviour. We leverage one user's prompts to help others, so the previous prompts and computational efforts don't go wasted. Mimicking open sourced developed programming languages characteristics. We are agnostic about the form — for every request we check what the ideal one is. Where the answer settles into an established process — a method, function, or algorithm — it can then run deterministically; and some blocks still make their own LLM calls when that genuinely is the ideal form. We optimize toward the cheapest form that works, not toward a rule. And because that logic is represented and managed directly in the UI, the platform doesn’t have to endlessly re-process or “understand” the prompt. In our system, every call to an LLM aspires to convert itself into a simpler, deterministic form of compute.