Anyone can demo an agent. Ather Forge is for the day after: deterministic logic where you need certainty, human approval where it matters, any LLM you choose, and every run recorded as graph structure you can query, replay, and defend.
One flow: trigger → agent → gate → output. This isn't a picture of the system: every block is a real node in the graph.
Most agent projects die between the demo and the deployment. Forge is built around the five moves that get you across and keep you in control once you're there.
The two coloured stations are the ones most frameworks skip: enforced human command, and evidence-driven iteration.
Not everything deserves an agent. We map your processes against what agents do well (repetitive judgment over connected data) and shortlist where payback is measurable and the blast radius is small.
Triage, reconciliation, and document pipelines share a shape. Forge gives you that shape as a starting point, so the first week is spent adapting logic to your business, not inventing plumbing.
From the first production run, every step, tool call, and decision lands in the graph. There is no “add observability later”: the runtime records itself.
Budgets, permission tiers, and approval checkpoints are enforced by the runtime, not suggested by a prompt. The agent asks before it acts on anything you've marked as yours to decide.
Replay any run, swap the model or prompt, and diff the outcomes. What to scale, what to fix, and what to retire stops being a debate. It's in the data.
A planner splits the work; specialists execute; a reviewer gates the result. Coordination happens through shared graph memory, so nothing gets lost in a hand-off.
Multi-step investigation with API access and durable memory: gather, cross-check, synthesize, and cite where every claim came from.
Answers grounded in your documents and systems through GraphRAG: current, permission-checked, and delivered with citations plus the path behind them.
Break a process into steps, decide what happens next and who executes it (human or agent), with the whole plan visible as a live graph.
The Ather Forge SDK is in development: Python-first, and deliberately small. A working agent is four decisions, not four hundred lines.
Name, role, model. Declaring it creates real graph structure: the agent exists as nodes and edges you can query.
Point it at your graph. It retrieves through GraphRAG and remembers with provenance.
Pick from the MCP catalog, tier the permissions, and mark which actions need a human.
Every run is inspectable live and replayable after. Iterate on evidence, not vibes.
from ather.ai.forge import Agent, Flow
assistant = Agent("ops-assistant",
role="Operations analyst",
model="any-llm-you-choose",
knowledge="ops-graph", # 2: GraphRAG + memory
tools=["mcp:jira.*", "mcp:slack.read"],
approve=["mcp:*.write"]) # 3: human gate on writes
Flow("daily-triage").run().watch() # 4: live, replayableAPI shown is directional and may change before release. Track the SDK on the developer platform →
Research, analysis, reporting, support, and operations: agents that plan and execute, not just chat.
Roles, tools, memory, tasks, and workflows: coordinated teams of agents with clear responsibilities.
APIs, databases, files, MCP servers, and enterprise systems: governed access, every call recorded.
Agents that understand entities, relationships, and dependencies, because their knowledge lives in AtherGraph.
Finance, legal, sales, operations, HR, including SAP payment reconciliation, matched and posted with a full audit trail.
Execution, inputs and outputs, cost, errors, and history, all recorded as graph structure you can query.
See the worked example: SAP payment reconciliation, end to end →
The pattern above, running against a real system: bank payment advices matched to open invoices in SAP (FI-AR / FICA), cleared within tolerance, exceptions routed to an AR clerk, and clearing documents posted back, with an audit trail for every posting.
Every match decision (which invoice, why, at what confidence) is recorded as graph structure. When the auditor asks why a payment was applied, the answer is a query.
Built to work alongside SAP's own assistant, not against it: through open interoperability, our plugin agents give Joule and other assistants what they don't have: the delivery and finance context around SAP, grounded in a graph they can't see on their own.
All planned or in development: labelled honestly, shipped when ready. Early-access partners shape what ships first. See the roadmap →
Fixed logic for the steps that must never surprise you; model judgment for the steps that need it; fallbacks for when an action doesn't go to plan. You decide which is which, and the runtime holds the line.
Any LLM, swappable without a rebuild. Tools through the open MCP standard: ours, yours, or third-party. Nothing about your automation is locked to us.
Token usage, latency, and cost land in the graph per run, per agent, per flow. Route cheap steps away from the model, reuse stored results, and scale with the bill in view, not discovered.
Inspect any step. Replay any decision with a different model or prompt and diff the outcomes. Catch drift and regressions from the record, not from user complaints.
You're ready to build. Start on a foundation that won't need replacing when it works.
The demos worked. Now you need governance, observability, and audit before go-live.
Agents are everywhere and nobody has the full picture. One graph control plane restores it.
A chatbot responds; a Forge agent completes work: it plans steps, uses tools, and finishes tasks. And unlike a chat log, every action lands in the graph as queryable structure: what it did, what it used, and why.
The runtime, not the prompt. Budgets, permission tiers, and human approval gates are enforced outside the model, so an agent physically cannot take an action you haven't granted.
Yes. Like the database it stands on, Forge deploys on-prem, in your private cloud, or air-gapped. Your data and your agents stay inside your perimeter.
Any. The model is a swappable building block, not a dependency. Change it per agent, per flow, or per replay, and compare outcomes on the record.
The Python SDK is in active development and coming soon. Early-access partners get it first and shape the API. Join the waitlist on the developer platform →
Join the teams building automation they can actually defend. Early-access partners get direct engineering access and shape what ships first.