Key Concepts
The vocabulary used across RamAIn, how the pieces fit together, and the mental model behind the platform.
RamAIn keeps its vocabulary small and consistent. This page defines every term you will see in the product and in these docs, then walks through how the pieces connect and the mental model that ties them together.
Glossary
The mental model: demonstrate once, run forever
Traditional automation asks you to translate your knowledge into someone else's language: a script, a flowchart tool, a recorder that captures brittle clicks. RamAIn inverts that. You already know how to do the task, so you do it once, in plain English, with an agent watching and helping in a real browser. The platform's job is to turn that single demonstration into something durable.
That is why the compile step matters so much. A session is a specific story: "on July 14th, someone looked up three travel books." The compiler reads that story and extracts the general shape of the task: which values were incidental (three, travel) and should become inputs, which steps were the actual work and should become agent steps, and which outputs mattered and should be parsed into structure. The result runs tomorrow with different values, on a page that has shifted slightly, without you maintaining anything.
Because the running unit is an agent rather than a recorded macro, the workflow tolerates the messiness of real websites. A moved button, a new banner, an extra confirmation step: the agent reads the page the way a person would and carries on, and it only stops to ask a human when a step genuinely needs one.
Where Agents fit around workflows
Workflows deliberately stay small: one browser task, done well, with clear inputs and outputs. Real processes are bigger than one browser task, and that is what Agents are for. An agent treats each published workflow as a single reliable step and composes it with everything a browser cannot do alone:
- Before the UI work: fetch records from an API, read a spreadsheet, filter with a code step.
- Around it: loop over records, run branches in parallel, pause for a human approval.
- After it: aggregate results, generate a CSV, post to another API, email the summary.
So the division of labor is: demonstrate the UI work once as a workflow, then describe the pipeline around it as an agent. Both are built by talking, both follow the same draft-to-published lifecycle, and both start from the same triggers.
How the pieces fit
Here is the full journey of one automation, in terms of the vocabulary above.
Step 1
A session in the Builder produces the evidence: pages visited, steps taken, notes recorded. You are chatting; the platform is taking meticulous notes.
Step 2
Saving compiles that evidence into a workflow: blocks connected on
a canvas, with inputs for the values that change per run, parsers
for the outputs, and variables flowing between steps. If the task
needed a login, the credential lives in Passwords and the graph only
carries a #key reference.
Step 3
Publishing promotes the draft and activates its triggers and API endpoint. Each start, whether from a click, a schedule, an email to the team inbox, or a POST, creates a run.
Step 4
Runs appear in Sessions, produce outputs and files, and can pause for human review or poll the team inbox and team phone for verification codes when a site asks for one.
Step 5
Published workflows become building blocks for agents, which wrap them in loops, API calls, code, and approvals to cover the whole process end to end. A Visual SOP can document any version for the people who never log in.
Where to go next
See every one of these concepts in action by building your first workflow.
The Build, Edit, and Test phases in depth.
How orchestration works: blocks, sandbox runs, and self-healing fixes.
Was this page helpful?