Yana AI · Documentation · Desktop App · Rust Runtime · Python CLI

I’m Vũ Văn Tâm, a Vietnamese developer based in South Korea. I began building the system that became Yana AI when I was 17.

Yana did not begin as a startup pitch or a polished application. It began as files on my own computer: Claude Code configurations, safety rules, prompts, hooks, and automation experiments that I used to make AI-assisted development more reliable. That early system was called YAMTAM ENGINE.

As I used it, the problem became larger than configuration. Different models and coding agents could write code, but they did not share one runtime, one capability boundary, one memory model, or one definition of when a human must take control. The files became a scaffold; the scaffold became a runtime; the runtime became Yana AI.

I work with Claude, Codex, Gemini, local models, and specialist agents as engineering collaborators. They help implement, review, test, and challenge decisions. I do not hide that collaboration, and I do not transfer responsibility to it: authorship is credited where possible, while architecture, risk acceptance, release authority, and the project’s direction remain human decisions.

My job is to make AI more capable without quietly making the human less in control.

The project has two histories: the code existed locally before this GitHub repository, and the public Git history begins later. I keep that distinction visible instead of turning uncertain dates into marketing facts.

The reported lineage is:

Claude Code configurations → GitNexus experiments → YAMTAM ENGINE → Yana AI

This history matters because Yana was not invented all at once. It grew from repeated failures, real CI breakage, unsafe automation, duplicated runtimes, stale documentation, packaging mistakes, and the need to distinguish “a file exists” from “a capability is genuinely wired and usable.”

One runtime. Any AI. Human-governed.

Build with AI. Govern what it builds.

Yana AI is a local-first, cross-platform control and runtime system for AI. It connects local models, cloud models, coding agents, project tools, memory, and automation to one native execution layer while keeping deterministic policy and human authority in the path.

It is not a foundation model and it is not tied to one provider. Yana does not try to replace Claude, Codex, Cursor, Ollama, LM Studio, or llama.cpp. It gives them a shared runtime and a governed boundary for what they may inspect, change, and execute.

AI can now read repositories, edit files, run commands, launch agents, call tools, and prepare releases. Intelligence is improving quickly, but operational control is still fragmented:

• each model or coding agent invents a different workflow;
• tool permissions are often mixed directly into UI or provider code;
• “safe”, “done”, and “approved” are frequently claims without evidence;
• local models and cloud models do not naturally share one governed execution layer;
• automation can become more autonomous without a clear boundary for when a human must decide.

Yana turns those questions into runtime behavior rather than policy text alone.

• A Rust runtime with native chat, streaming, cancellation, sessions, routing, missions, capabilities, health, workspace, and OS surfaces.
• Local model paths for Ollama, LM Studio, llama.cpp, and compatible local endpoints, alongside cloud-provider integrations.
• Project adapters for Claude Code, Codex, Cursor, and Antigravity.
• More than 2,000 skills, 100 specialist agents, 170 commands, and 60 deterministic hooks maintained from canonical sources.
• A multi-platform Electron desktop application and a Rust terminal chat experience connected to the same runtime direction.
• Project memory, evidence, audit, integrity, quarantine, and human approval mechanisms.
• Cross-platform work targeting macOS, Linux, and Windows.

These numbers describe a fast-moving project, not a promise that every surface has equal maturity. I keep architecture-health reports and known limitations public because runtime truth matters more than a large feature count.

Yana’s autonomy model is intentionally asymmetric: routine work should become automatic, while irreversible or high-impact actions stay human-controlled.

Observe → Recommend → Prepare → Execute safely → Escalate high-impact decisions
                                                  ↑
                                         human authority remains

I decide the product principles, the autonomy boundary, which runtimes and interfaces belong in Yana, and where the project should remain deliberately conservative.

yana-rt is the deepest core. Terminal chat, desktop UI, project adapters, MCP surfaces, and future interfaces should converge on its capabilities rather than create independent execution paths. When duplicate implementations appear, I treat that as architectural debt.

I investigate CI failures, release breakage, packaging gaps, hook races, platform differences, runtime regressions, and drift between documentation and executable behavior. A feature is not complete because its file exists; it must be reachable, wired, tested, packaged, and observable.

Agents can propose architecture, write patches, review code, and run verification. I decide whether high-impact changes ship. Yana’s own development process follows the same philosophy the product enforces: AI can act, but human authority defines how far it may go.

• Making the capability runtime the single source of truth across chat, MCP, project tools, and host operations.
• Deepening yana-rt integration so terminal and desktop interfaces share one runtime rather than duplicate behavior.
• Improving local AI sessions, memory recall, context management, model switching, and provider health.
• Building reliable cross-platform supervision for CPU, GPU, process, service, and Yana system health.
• Making releases reproducible without depending exclusively on GitHub-hosted automation.
• Raising autonomy for routine work while preserving explicit human gates for destructive, security-sensitive, and production actions.
• Continuously separating what is truly wired from what is only implemented, documented, experimental, or planned.

Build > Talk
Ship > Promise
Verify > Assume
Evidence > Confidence
Human authority > silent autonomy

I use AI heavily, but I do not treat AI output as truth. My workflow emphasizes:

• inspect the real code before making architectural claims;
• test the execution path, not only isolated helpers;
• record authorship and review evidence;
• publish known limitations instead of hiding unfinished wiring;
• prefer small reversible changes over impressive but fragile rewrites;
• keep destructive and production actions explicitly human-gated.

My strongest interest is not a single language. It is the boundary between AI intelligence, native systems, developer tools, automation, and human control.

Yana AI learns from open-source projects, research, runtime patterns, and real operational failures. When an upstream project directly influences an implementation, I aim to preserve license information and attribution in the relevant source or documentation.

Contributions are welcome—especially from people interested in Rust runtimes, local AI, terminal interfaces, cross-platform systems, safety engineering, reproducible releases, and human-centered automation.

Your AI can act. But who decides how far it can go?
_{I am building Yana AI so that answer remains visible, inspectable, and human.}