|
Autonomous automation agent · orchestrator-ready by design · powered by n8n-as-code today |
Yagr is designed to sit above execution orchestrators. n8n is the supported orchestrator today, and will remain the primary one. Support for additional orchestrators may be added later as an optional choice.
If you want to see Yagr working before reading the full product story, start here.
npm install -g @yagr/agent@latestyagr onboardThis connects three things:
- your execution orchestrator connection, which is n8n
- your default model
- your optional messaging integrations, including Telegram
After onboarding, Yagr is ready. If you configured Telegram during onboarding, anyone who messages your bot will receive an automatic link to connect their chat — no extra step needed.
yagr start # start gateways in the background (Telegram, etc.)
yagr tui # open a terminal chat session
yagr webui # open the local web interface
yagr stop # stop the background gatewayyagr start launches messaging gateways as a background daemon and returns to your shell. Use yagr tui or yagr webui at any time to open an interactive session directly.
yagr paths
yagr reset --dry-run
yagr reset --scope full --yesTo remove the global CLI package itself:
npm uninstall -g @yagr/agent
Yagr is built on top of n8n-as-code
Yagr rely on the underlying n8n-as-code technology, workflow GitOps model, schema grounding, and editor tooling
Open the n8n-as-code repository
⚠ n8n version compatibility — The node schema bundled with n8n-as-code is built against the latest stable release of n8n. For best results, keep your n8n instance up to date. Using an outdated instance may cause generated workflows to reference node type-versions not yet supported by your instance, which n8n renders as broken nodes in the canvas.
Read next if you want more than the fast path:
Most AI agents today execute tasks by writing ephemeral scripts or firing blind API calls.
It works once, but it creates a black box:
- hard to audit
- hard to secure
- hard to maintain
- easy to break
Yagr takes a radically different approach.
Yagr is a general-purpose autonomous agent, but its execution layer is grounded in deterministic workflows.
When you ask Yagr to sort your emails, draft replies, monitor Stripe churn, or automate an operations loop, it should not disappear into a temporary Python script that nobody can inspect tomorrow.
Instead, Yagr dynamically architects, validates, and deploys a real workflow underneath the conversation.
That means Yagr is an automation agent where:
- you express intent in natural language
- Yagr plans against a grounded node ecosystem
- Yagr generates and validates a workflow on a deterministic execution orchestrator
- the resulting workflow becomes durable, executable memory and muscle that Yagr can revisit later
For the user, it feels like magic chat.
For the engineer, it is auditable, inspectable, safer, and grounded in strict ontology rather than improvisation.
The workflow is the agent's durable memory and muscle.
|
Yagr starts from what you want to automate, not from manually wiring implementation primitives. |
Generated workflows are not throwaway output. They are persisted intent that Yagr can inspect, explain, modify, and extend. |
Yagr stays above the execution orchestrator. n8n is the supported orchestrator today, and will remain the primary one. Support for additional orchestrators may be added later as an optional choice. |
|
|
User intent
-> Yagr agent
-> Orchestrator interface
-> n8n via n8n-as-code (primary, long-term)
-> future: optional support for additional orchestrators
-> workflow is generated, validated, deployed
-> workflow becomes durable executable memory
This separation is deliberate:
- gateways are thin surfaces
- the agent is the reasoning layer
- the engine executes automations
- workflows are the lasting artifact, memory, and muscle
yagr setup configures three things:
- your current orchestrator connection: today that means an n8n instance, API key, project, and local sync folder
- your default model: provider, model, API key, optional base URL
- your optional messaging integrations: for example Telegram
Yagr stores that state in its own home so the product does not depend on whatever repo or shell happens to be open.
- Yagr is the agent. It should stay above the execution orchestrator.
- Gateways are not the brain. Telegram and TUI are surfaces into the same agent loop.
- Workflows are memory and muscle. They persist how the problem was solved and they execute it reliably over time.
- n8n is the primary orchestrator. It is the one Yagr supports today and will keep as its main backend. Support for additional orchestrators may be offered later as an optional choice — the product story does not change.
If gateways are not responding or something feels stuck:
yagr stop # stop the background gateway daemon
yagr gateway status # check whether a daemon is currently running
yagr start # restart itIf you need to re-share the Telegram onboarding link (for example when linking a second chat):
yagr telegram onboardingTo reset everything and start over:
yagr reset --dry-run
yagr reset --scope full --yesIf you are contributing from this repository instead of installing the published package globally, use the repo-scoped development flow:
npm install
npm run build
npm run yagr:onboard
npm run yagr:startThese development scripts intentionally target .yagr-test-workspace so local work does not pollute your real ~/.yagr home.