Launching today
Agently
Your whole stack, running itself!
130 followers
Your whole stack, running itself!
130 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.
Huge congrats @omarships on hitting the leaderboard.. qq what's the average millisecond latency overhead between an incoming trigger event and agent execution?
@priya_kushwaha1 Great question.
We keep the trigger path deliberately thin: an incoming event (a webhook, or a manual dispatch from Command Center) is acknowledged and the run is handed off asynchronously, so the trigger-to-execution overhead is small and roughly constant.
The latency that actually dominates is the agent loop itself: brain retrieval + model inference + tool calls. That's seconds-scale, and it's where we spend our optimization budget (prompt caching, a frozen prompt prefix, incremental cache breakpoints so repeat runs stay fast).
Happy to go deeper. DM me and I'll share the real prod numbers we're seeing.
Thanks, Omar That makes sense, I also sent you a DM just waiting for your response. Looking forward to learning more about the production latency numbers.
@omarships @priya_kushwaha1 This one's my corner 🙂 The pipeline: trigger comes in → validate + persist + hand off to a stateless agent service, all off the request path → then the loop runs (retrieval → inference → tool calls, iterating to done). We tag every stage with correlation IDs so we can see exactly where the time goes, and the trigger→handoff segment is by far the cheapest part. It's the tool round-trips and inference that set the pace. Ping me and I'll share real traces with the exact split.
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.
@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
@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 🔥
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
@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.
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?
@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.
The "running itself" promise is the dream and the fear at once. As a solo builder leaning hard on agents, my honest worry is trust: how much can I actually hand off unattended before I need to babysit again? Curious where you draw that line.
@virko_kask Honestly the most important question in this space, and I'd be skeptical of anyone who answers it with "just trust it."
Our line is the point of consequence. The agent runs on its own for the most part: drafting, research, pulling context, prepping the deliverable. But anything that ships or touches the outside world (sends an email, posts, spends money) hits an approval queue and waits for you.
Two things keep that from being annoying instead of empowering: it remembers what you reject, so it stops proposing the stuff you don't want, and you can widen that line per action type as trust builds. You start at "propose everything" and move toward "send the routine follow-ups on your own."
So you're never babysitting, you're reviewing. And you review less over time. Trust should be earned, so we built it to be earn-able.
@virko_kask Ahmad here, I own the agent loop. The thing that lets us make that promise honestly: the guardrail lives in the runtime, not the prompt. Every tool call passes through a policy gate before it executes, first-deny-wins. Anything classified as consequential gets intercepted before it runs and dropped into an approval queue. When you approve, we replay the exact call, so what executes is byte-for-byte what you signed off on, no re-interpretation in between. There's a kill switch and per-run budgets so a bad run can't spiral. We're not asking the model to please behave, we're structurally stopping it from shipping without you.
honestly the "one brain that never forgets" pitch is what pulled me in, super cool approach. one thing i'd love though is a way to set confidence thresholds before an agent acts on its own. like if a Stripe charge fails and it's over a certain dollar amount, ping me first instead of just shipping the resolution. basically a safety net for the autonomous stuff so i'm not blindsided when something big gets handled without a heads up.
@erkanaltnbkaas Good news: the enforcement layer this needs already exists. Every tool call runs through a policy gate before it executes, so "this action requires a human" is already how we stop consequential stuff from shipping. What you're describing is making that gate conditional on the tool's inputs (amount > $X, refund on an enterprise account, more than N per day → require approval). That's a policy predicate, and it's exactly the layer we're building user-facing rules on top of. The rails are there, we're putting the dashboard on them. Sharp spec 🙂
@erkanaltnbkaas You basically just described our philosophy back to us, so this is a yes. You draw the line, and it shouldn't be a blunt on/off, it should be conditional. "Handle refunds under $50 on your own, ping me above that" is exactly the kind of rule we want in your hands. The point of Agently isn't maximum autonomy, it's autonomy you're never surprised by. You won't get blindsided by something big, because you decide what "big" means. Thank you for putting it so clearly 🙏