Graft AI
Turn company operations into a living map for agents
123 followers
Turn company operations into a living map for agents
123 followers
Most agent tools assume clean APIs. Graft starts where companies actually work: legacy apps, internal tools, and workflows trapped behind screens. It learns how the work gets done, turns it into a living operational map, and gives agents stable tools with permissions, approvals, audit trails, and verification built in. When the underlying UI changes, Graft detects the drift and repairs the workflow without breaking the agent interface.
Graft AI
Building a receipt-scanning feature right now and even at my tiny scale, the "verification" part is the hard bit — I ended up schema-validating every LLM response and failing closed on anything unparseable, because silently-wrong output is worse than an error. Curious how you handle the case where the workflow succeeds mechanically but the result is semantically wrong — is verification rule-based per workflow, or learned?
Graft AI
@cannetjam That is exactly the failure mode we care about. Graft uses a hybrid verifier: explicit schemas, business invariants, and source-of-truth checks define what “correct” means, while learned models detect semantic mismatches and novel edge cases. Learned signals can quarantine a run or propose a new rule, but they never silently change the contract; ambiguous results fail closed or go to a human.
@ychampion Makes sense, keeping the learned side advisory-only is the honest way to do it. Good luck with the launch!
Graft AI
@cannetjam thank you
docs go stale in a week so i like the living map idea. how does it stay updated without me babysitting it?
Graft AI
@doganakbulut hello, good question. You shouldn’t have to babysit it. Graft watches real workflow executions and compares decisions, exceptions, and outcomes against the current map; when something changes, it proposes a clear diff, tests it in shadow mode, and only asks for review when the change is risky or uncertain. Normal work keeps the map current, while people step in only for meaningful exceptions. We're working on sandboxed environments and many cool features, it self-updates it self. This is not an agent, its an infra running to understand how your company operates, connects to software your company uses, extracts the domain knowledge from people to create a operating knowledge map (with our advanced memory systems) usable by agents consistently. For example it understands how refunds work, so this won't save it as a doc, it'll see how it functions in your company and map it out, next time something changes it'll update itself. It is deeply integrated to your system and connected to the tools you use and is like an evolving brain
Ask any questions if you have! if you're interested and want to talk, you can sign up for the waitlist at graft.axcelner.com
Dial
the self-healing part for legacy UI drift is the piece nobody else seems to be tackling well, most RPA-style tools just break silently when a button moves. what's the actual gap between the UI changing and Graft detecting + repairing it, are we talking minutes or does it need a human to confirm the fix before it goes back into production
Graft AI
@omri_ben_shoham1 For simple drift, like a moved or renamed control, Graft detects the mismatch on the first failed run, stops before the side effect, and can usually generate and re-test a repair within minutes. Low-risk fixes can be re-certified automatically, while anything that changes business logic or could cause an irreversible action waits for human approval before going back into production. There are types of HITL, depends on the confidence scores, and this is not just an agent, its an agent infra that continuously learns. If you're interested and want to talk, sign up for the waitlist at graft.axcelner.com, let me know if you have any questions
Graft AI
@omri_ben_shoham1 also this is not exactly RPA, I suggest reading this: https://graft.axcelner.com/blog/the-workflow-access-gap
building stable tools instead of chasing every API makes sense, but that shifts a lot of ongoing maintenance onto graft's side to keep those maps accurate as companies change.
Graft AI
@dustin_warren Exactly, which is why maintenance is part of the product: Graft continuously detects UI and business-logic drift, fails closed when a workflow no longer matches its certified behavior, and re-verifies every update before agents can use it again.
One thing that would help us adopt this faster is a visual timeline view inside the operational map, so we can scrub through past workflow executions and see exactly where drift or failures happened. Right now troubleshooting at scale feels like guesswork.
Graft AI
@alpergrbzobpev Yes, that is exactly where Graft is headed: every run becomes a replayable visual timeline, so teams can scrub through decisions, handoffs, failures, and drift instead of debugging from scattered logs. Your company owns the resulting operational knowledge base, and every employee correction makes it smarter, much like a team continuously improves a shared codebase for agents. If you're interested and want to talk, The waitlist is live at graft.axcelner.com.
Operations as a map agents can walk is close to what I do per-client, structured facts an AI can't step outside of. Mine is one brand, yours is a whole company, and I suspect the hard part scales badly. How do you keep the map current when the operations change weekly?
Graft AI
@vladimir_iudin That is the hard part, so we treat the operational map like a versioned codebase, not a static knowledge graph. Every execution, exception, and employee correction is compared against the current map; changes are proposed as reviewable updates, tested in shadow mode, and only promoted after they pass verification. The map stays current because the company continuously contributes to it through normal work, instead of relying on a quarterly process-document rewrite. We're building knowledge graphs, real time data flow mechanisms, more info soon.
@ychampion Shadow mode promotion is the part I want to steal. I do a much smaller version of this, per-client fact bases with a gate that refuses to generate anything not backed by a stored fact, but updates to the facts themselves are still manual and that's where staleness creeps in. One thing I don't get yet: what counts as a failed verification for a process change? Bad code fails a test. A bad "how we handle refunds" update can look fine until a customer hits it.
Graft AI
@vladimir_iudin this is the knowledge we have to extract, it can be possible by recording situations, creating twins of it, asking for approval when not sure, there are many ways. Even we're exploring new architectures.