Agently
Your whole stack, running itself!
601 followers
Your whole stack, running itself!
601 followers
Every other tool answers, retrieves, or runs brittle rules. Agently holds your whole company in context and does the work. 100+ connectors flow into one brain that never forgets. It links a Stripe event to a Slack thread to a Linear ticket on its own. When something needs doing, Jarvis routes it to an agent that runs it end to end: triggered, running, shipped. The work lands without you, nothing falls through the cracks. Connecting takes minutes. The layer between today's AI and tomorrow's AGI.
Congrats on the launch! The temporal knowledge graph is really interesting. How does it decide a fact has gone stale, like a customer that churned or a deal that moved vs just keeping the newer fact alongside the old one? Really like that you framed the brain as the moat and the agent as the commodity
Agently
@artstavenka1 Appreciate it and definitely the right question 🙏
The way we see it: your company's brain should understand that reality changes, not just pile up facts. A customer isn't "active" forever, they're active until they churn. A deal doesn't sit in one stage, it moves. So the brain doesn't keep the new note next to the old one and shrug. It understands that "churned" replaces "active" because they can't both be true, and it remembers exactly when that flipped. You get the current truth and the history of how you got there. That's the difference between memory and a filing cabinet. Ahmad will give you the actual mechanics
@artstavenka1 Thanks Omar. So conceptually Omar's answer will be easier to understand but here's a more technical breakdown.
Here's the mechanic. Staleness isn't a timer or "newest overwrites," it's contradiction detection at write time. When a new fact comes in, we check whether it conflicts with an existing relationship. "Customer churned" contradicts "customer active," and a deal has one current stage, so those old edges get invalidated (we stamp them with an end time rather than deleting them). Additive facts that don't conflict, bought product A then product B, just coexist. So invalidation is semantic, not chronological: mutually-exclusive states supersede, independent facts accumulate. And because it's bi-temporal, you can still ask "when were they active" and get the exact interval. Honest caveat: the contradiction call is model-assisted, so clean state transitions are reliable, and for genuinely fuzzy ones we keep both and lean on recency + provenance instead of forcing a merge.
Honestly the linking between Stripe, Slack, and Linear without me setting anything up kind of freaked me out in a good way. Curious how it handles edge cases when the context gets messy though.
@saadetpz2y That auto-linking is entity resolution on hard signals (shared email, domain, IDs), so it connects the same customer/thread/ticket across tools with zero setup. For the messy stuff the rule is: degrade to asking, not guessing. Strong signal it acts, weak or conflicting it flags and defers to you instead of forcing a match. Edge cases get surfaced, not papered over.
Agently
@saadetpz2y Appreciate that 🙏
Here's the belief behind it in a less technical manner: messy context isn't an edge case, it's the normal state of every company. Tools disagree, data goes stale, half of it lives in someone's head. So we made a deliberate call early: the system should be honest about what it doesn't know rather than confidently wrong.
Sounds small, but it's the whole product. The fastest way to lose a founder's trust is one confident action taken on bad data. So when context gets messy, Agently narrows down and tells you instead of guessing and shipping. We'd rather look a little less magic in that moment and earn the right to run more of your company over time.
The "freaked me out in a good way" part is the payoff of getting the boring foundation right. Glad it landed 🙌
Triforce Todos
Agently
@abod_rehman Thank you 🙏
"chatbot with extra steps" might become our tagline.
The first workflow is almost always the recurring, boring, high-context one, the thing that quietly eats your Sunday. Weekly updates for the team or investors, personalized cold outreach, a competitor or account teardown.
It's the work that needs your whole company's context but not your genius, which is exactly what the brain unlocks. Once that one lands, people get bold fast. What's the one eating your week?
@abod_rehman From the eng side there's a reason it's usually those: the first workflow people trust is read-heavy. Pull context from the brain, synthesize, draft. No consequential action, so nothing needs sign-off, which makes it the perfect on-ramp, real value at zero risk. It also stress-tests the brain in the best way (retrieval + cross-tool linking) before anyone hands it anything irreversible. So teams start with "summarize and draft," then graduate to "go do it" once they've watched it be right a few times 🔥
How do you handle data consistency across 100+ connectors, especially when dealing with concurrent updates or network failures? Is there a specific data modeling approach or conflict resolution strategy in place?
Agently
@aymnart Actually Great question (might give you the award), and the honest answer starts with humility: you can't wrap 100 third-party systems in one clean transaction, and any tool claiming to is lying to you. So we designed for the real world, where retries, duplicates, out-of-order events, and half-failed syncs are the normal case, not the exception. Every write is idempotent, so a flaky webhook firing three times still lands once. And we reconcile truth by when things actually happened, not when they showed up. The payoff for you: a network blip or a connector hiccup never corrupts your brain which remains the source of ultimate truth, it just converges on the right picture once things settle. Ahmad can take you under the hood 👇
@aymnart Here's the mechanic. Consistency across connectors is eventual, not transactional, we don't pretend to two-phase-commit across Stripe and Slack. What makes it safe:
Idempotency — every synced record is keyed by (connection, source-record-id) with a uniqueness constraint, so at-least-once delivery from retries or failures collapses to exactly-once effect. Replays are free.
Failure handling — sync writes run off the request path, each tracked by a status column, so a failed or partial sync is observable and retryable instead of corrupting state. Webhooks ack fast, then process async.
Ordering + conflicts — writes carry an explicit reference time, so concurrent updates reconcile by when the event actually happened, not arrival order, and conflicts resolve through the temporal graph (contradiction detection + validity intervals), not last-write-wins.
So the model is idempotent ingestion + temporal reconciliation. Boring on purpose, because boring is what survives 100 flaky APIs.
Solo founder here, already running most of my ops through AI agents, so this one hits home. The part I'm curious about is trust: when Jarvis links a Stripe event to a Slack thread and acts on its own, what happens when it gets something wrong? Is there a review/undo layer before actions land, or do I find out from the logs? That's what would decide whether I let it anywhere near billing.
Agently
@dmitrii_tolstikhin The data is coming straight from stipe and slack, the brain makes correlations based on how the data relates to each other through normalization, algorithms and embedding. The brain goes through a series of processes including validation and invalidation. Jarvis does not have access to the brain to act its own. In any case, the last de-risk attempt we integrated is -> you review before it lands, you never find out from the logs, and nothing hits Stripe until you say yes. We gate before the action instead of promising undo, because you can't cleanly un-charge a customer, so billing stays in the always-approve bucket until you decide otherwise.
@dmitrii_tolstikhin Quick correction on the mechanics: ingestion, normalization, and embedding happen in the brain as a separate layer, so by the time Jarvis touches a Stripe event and a Slack thread they're already resolved into one grounded context built entirely from your source data, not stitched together at action time. Execution then sits behind an approval status no task passes without your sign-off, so even a bad read can't become a bad action, it stops at the gate.
There are such a thing as recurring tasks and skills (patterns your brain recognizes from your data then makes them into automated workflows). Those you approve and audit once under your own tolerance, then you don't need to going forward.
How do you handle ownership and auditability when Agently routes work end-to-end across tools; can teams see who/what made each decision, why it was taken, and roll back or reassign actions if needed?
Agently
@swati_paliwal Great question, and it's the line between a demo and something you'd actually run a team on.
Accountability is first-class: every action carries who proposed it (which agent), who approved it (which human), the reasoning, and the context it pulled from, so "who decided this and why" is never a mystery, it's on the record.
On rollback: anything reversible has a full trail and you can course-correct, but for irreversible actions we deliberately put the control before the action, not after, because you can't cleanly undo a sent email or a charge. Ahmad can walk the audit mechanics 👇
@swati_paliwal On the mechanics: every action writes an audit record with the actor (the specific agent run, or the human approver), a timestamp, the reasoning, and the exact context it pulled from the brain, all traceable end to end by correlation ID across the tools it touched. Because we approve-and-replay, the executed action is provably the one a named human signed off on, no drift between "approved" and "ran."
On rollback and reassign, I'll be precise rather than oversell: reversible actions have a trail you can act on, reassigning ownership routes through the same task/approval layer, and for irreversible side effects the real control is the pre-execution gate. We prevent instead of promising a rollback physics won't allow.
Congrats on the launch @ahmadhajj @omarships
The line that actually landed for me was the Stripe → Slack → Linear example - that's where I could picture the product working. That's a key point and something beneficial to lead with, as it establishes the problem that Agently solves.
Who do you see as the Ideal User for Agently - Solopreneurs? Large teams?
What's the one workflow you'd want a first-time user to feel relief on immediately?
Agently
@ahmadhajj @anna_ludwinowski
On the ideal user, everyone who is using AI for work can and should use it. In our Cohorts, we had solo founders, small teams, mid sized startups, mid market companies, VC's even and 1 FAANG Enterprise.
The real question is, who benefits the most: today it's the lean operator, solo founders and small teams (think under ~20) who are drowning in tools and feel the coordination tax hardest. Big teams benefit too, but that's where the pain is sharpest and the "oh, I don't have to be the glue anymore" hits fastest, so that's who we build for first.
On first relief: exactly the loop you liked, the moment a signal in one tool becomes handled work in another without you shuttling between tabs. A failed payment that turns into a drafted, context-aware follow-up and a Slack heads-up, waiting for your yes. First time someone watches that happen, the relief is physical.
Really appreciate you 🙌
@omarships Honestly, when I first read the description, I made the assumption this was geared towards bigger teams/enterprise. Now, I see tremendous benefit to lean Founders, such as myself. Knowing the stuff is being monitored and looked after is a huge relief. Will be giving it a try - thanks!
Agently
@anna_ludwinowski Enterprise feel the pain the most. Solofounders are the ones who benefit the most. Thats the way we have seen it take place through out our private betas.
Since solofounders get to have a source of truth and extract strategy from the context, they are able to iterate, pivot and ship much quicker. Really is kind of like AGI
@omarships @anna_ludwinowski Thanks Anna 🙏 — You're right that we should lead with the Stripe → Slack → Linear moment; it's the clearest picture of the actual problem: today you're the glue between tools, and that coordination tax is invisible until someone removes it.
Omar nailed the who and the first-relief, so I'll just add the part that makes it safe to love: every one of those cross-tool actions comes to you as a drafted, context-aware proposal waiting for your yes — nothing fires blindly. You get the relief of "handled" without giving up control. That's the line we're building everything around.
Really grateful for the thoughtful questions 🙌
@ahmadhajj Yes, that's the line- autonomous execution with a human still holding veto. You can feel the relief coming through!