Agently - Your whole stack, running itself!

@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.

@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.

@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.

@amraniyasser You just articulated our entire bet, thank you 🙏

It bends upward, and the reason is the part people miss: connecting sources is table stakes, that curve does flatten once your stack is in.

What keeps compounding is everything that happens after, every correction you make, every decision you approve or reject, every "no, do it this way." That gets encoded, so the brain stops just knowing your data and starts knowing your judgment.

That's the moat and the switching cost you're pointing at: a competitor can copy the features, they can't copy six months of your company's context and your decisions living in one place. The data is the commodity. What you've taught it is the moat.

@omarships  @amraniyasser from a more technical standpoint:

Two curves here: raw source-connection does plateau once your big tools are in, you're right.

But the graph keeps compounding on a different axis, entity resolution links more previously-siloed things over time, the temporal history deepens, and every correction or approval becomes a durable signal, so the value curve keeps bending up well past "everything's connected."

@busmark_w_nika Thank you 🙏

The Trello-familiarity is intentional, we wanted the surface to feel obvious on day one.

But the board is just the window. Underneath it is a company brain that ingests your whole stack, plus agents that actually do the work: they pull the context, draft the deliverable, run it across your tools, and drop it back for your sign-off. So"Trello for agents" + a board that fills and clears itself.

Really appreciate it, GL right back 🙌

@busmark_w_nika Hahaha, love it. From where I sit it's almost the inverse of Trello: the board isn't the product, it's the control surface over an actual agent runtime. Every card is a real run with governance behind it, an approval queue and audit trail, and the agent proposes then waits for a human on anything that ships. The automations aren't bolted onto a board. The board is a window into the execution layer. 🙌

@omarships Looks super cool. Will give it a try!

@omarships Super excited for this launch. First company of its kind

@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.

@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  @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 🙌

@suryansh_tiwari2 Thank you, this genuinely made our day 🙏

You captured it perfectly.

The way we think about it: the agent is the commodity, the brain is the moat. Agently pulls your whole stack into one living temporal company brain, so Jarvis (our orchestrator) never knows your company better than even your cofounder. It cross-references that context, drafts the real work across your tools, and opens it for your sign-off before anything ships.

And the brain compounds the more you feed it, so it gets sharper and more yours over time. That's the part we're most excited about. Grateful for the support, especially today 🚀🔥

@suryansh_tiwari2 Appreciate it 🙏 The part I'm proudest of on the eng side: agents don't get your company stuffed into a giant prompt. The brain is a temporal knowledge graph, and retrieval is a tool call the agent makes when it needs something. So it stays grounded, doesn't blow the context window, and can reason across tools without hallucinating the state of your company. Genuinely fun to build.

@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 🔥

@ahmadhajj  @kate_ramakaieva Great question, and it's exactly why the brain is a temporal knowledge graph and not a vector dump.

We don't do "latest tool wins" or silently overwrite. Every fact lands with a timestamp and its source, so when two tools disagree, both are kept, with provenance and when each was recorded. Resolution is temporal first: newer information supersedes stale facts, and the graph invalidates the outdated version instead of pretending it never existed. Recency and source both factor in.

And when a conflict is genuinely ambiguous, the agent surfaces it instead of guessing: "these two disagree, here's each side and when." Which ties back to the sign-off model, you resolve reality, it acts on it.

So conflicts aren't resolved by hiding them. They're resolved by remembering everything, when it was true, and where it came from.

@omarships  @kate_ramakaieva This is my favorite part 🙂 Under the hood it's bi-temporal: every fact carries when it happened and when we ingested it as separate axes, so "my CRM updated late" and "the thing actually happened Tuesday" don't get confused. Writes are idempotent per source record, so re-syncing a tool doesn't spawn phantom conflicts. When new info contradicts old, we invalidate the specific relationship rather than deleting history, and retrieval is a query over that graph, so the agent pulls a resolved current view but can still see the contradiction and its provenance. For genuinely ambiguous cases we flag, we don't auto-merge and hope.