How to Build an AI Agent in LedgyX: A Step-by-Step Guide
If you've used no-code automation tools before, you already know the shape of the problem: something happens, and you want software to react to it β intelligently, not just with a fixed rule. That's what an agent is in LedgyX: a configured unit of AI behavior that gets launched by a trigger and does its job using a set of skills you've explicitly given it.
This guide walks through the building blocks and how to connect them into your first working agent.
The building blocks
LedgyX's agent builder is a node-graph canvas β you compose agents visually instead of writing orchestration code. Four node types matter here:
- Trigger β the event source that launches a run.
- Agent β the reasoning unit; this is what actually "thinks" and decides what to do.
- SystemSkill β a capability you attach to an agent (send a Telegram message, read a file, transcribe audio, and so on).
- Event β represents something that happened, which a trigger or skill can act on.
Edges between nodes declare relationships rather than a literal data pipeline. For example, a
HAS_SKILL edge from an Agent to a SystemSkill means "this agent is allowed to use this
capability" β it's deploy-time configuration, not a step-by-step flowchart the way some
automation tools model it. Once deployed, the agent decides at runtime which of its available
skills to use, based on what the trigger handed it.
Step 1: Pick a trigger
Every agent needs something that starts it. LedgyX currently supports four independent trigger types, each with its own activity/firing log so you can see exactly when and why a run happened:
- Webhook β a generic inbound HTTP endpoint, useful if another system in your stack should kick off the agent directly.
- Cron β scheduled runs, for anything that should happen on a timer rather than in response to an event.
- Telegram β a bot listens on a chat and can hand the agent text, voice notes (transcribed automatically), photos (described to the model), or forwarded documents β not just plain text.
- Google Drive β watches a folder or file for changes and fires a run when something changes, using real push notifications rather than polling.
For a first agent, Telegram or a webhook are usually the fastest to test β you can trigger a run on demand instead of waiting for a schedule or a file change.
Step 2: Give the agent skills
An agent without skills can reason, but it can't do anything. Skills are modular β you attach only what a given agent needs:
- Sending or replying on Telegram
- Transcribing audio
- Viewing/describing images
- Forwarding attachments
- Listing or reading files from a connected Google Drive
- Saving generated output back into LedgyX's own File Manager
Each skill you attach becomes a HAS_SKILL edge from the Agent node. Keep this list narrow at
first β an agent with two or three well-defined skills is easier to reason about (and debug) than
one with everything switched on.
Step 3: Connect trigger to agent
With a Trigger node and an Agent node (with its skills attached) on the canvas, connect them. This is the whole "wiring" step β there's no separate orchestration layer to configure. The trigger's payload (a Telegram message, a webhook body, a changed file) becomes the input the agent reasons over on that run.
Step 4: Test it and read the firing log
Every trigger type logs each attempt β filtered or not, with a reason β so if a run didn't happen the way you expected, the firing log is the first place to check. This is especially useful while you're still tuning which events should actually reach the agent versus get filtered out.
What's next
Once the basic loop works, the two things worth exploring next are Google Drive triggers (for automating around files landing in a folder) and the File Manager's API-key upload endpoint, which lets an external system push a file in and fire the same automation a human drag-and-drop would. We'll cover both in follow-up posts β along with a full screen recording of building an agent from scratch in a real workspace.