Launched this week
Agently
Your whole stack, running itself!
592 followers
Your whole stack, running itself!
592 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.
Ahmad — the "writes carry an explicit reference time, conflicts reconcile by when the event actually happened, not arrival order" answer to Aymen is the detail I'd want to poke at. WinBidIQ ingests federal opportunity data (SAM.gov postings and amendments), and our version of "reference time" is messier than an internal system's clock: an amendment can get issued and only show up in the feed hours or days later, sometimes out of order relative to the original posting, and occasionally a correction supersedes a correction. For a one-way external feed like that, where you don't control the source and can't always trust its own reported timestamp either, does Agently's reference-time model take the source's self-reported time as ground truth, or is there a layer that sanity-checks it against ingestion order when the two disagree?
@medal411 You've nailed the exact hard case, and honestly it's the line between a toy and a system: a one-way feed whose own clock you can't trust, out-of-order amendments, and corrections superseding corrections.
Short answer: we don't take the source's self-reported time as ground truth, and we don't collapse it into ingestion order either. It's bi-temporal, so both are first-class and stored separately. The source's reported time is treated as a claim (an attribute of the event), and our ingestion order is always retained independently, which is what lets the two disagree without forcing a destructive pick. When a correction supersedes a correction, each one invalidates the prior with a validity interval, so the lineage stays intact even when they land out of order.
Where I'd rather be precise than hand-wavy: for a feed like SAM.gov, where the timestamp itself is unreliable, the right reconciliation isn't a global rule, it's source-specific logic in the adapter. That's where you'd encode "order on the amendment/version sequence, not the reported clock," since those postings usually carry a monotonic version that's safer to trust than the timestamp. Some of that is turnkey, some we'd tune for your exact feed, and I'd rather scope it with you than oversell one answer.
Genuinely a fun problem. DM me and let's go deep.
@ahmadhaj Ahmad, bi-temporal reconciliation on reference time vs ingestion order is a clean answer, thanks for walking through it. That resolves what the record converges to. The follow-on question about whether an approved action re-reads at execution is a separate one — happy to take that off-thread rather than keep stacking this comment section.
Agently
@medal411 Ahmad gave you the how, here's the principle: a source's clock is a claim, not the truth, so the brain reconciles reality rather than trusting whatever landed last. For a feed as adversarial as SAM.gov that's not a generic setting we'd flip, it's something we'd tune with you. Genuinely our favorite kind of hard, let's get into it.
the policy gate + approval queue answers in this thread are the most thorough I've seen on this, but they're all about what the gate does. what I haven't seen addressed: who can loosen it, and is that change logged the same way an agent action is? "handle refunds under $50 on your own" is a great rule until someone quietly bumps that number on a Friday and nobody notices until the damage is done. is changing the policy itself a consequential action that goes through the same approval/audit trail as everything else, or is it just an admin setting anyone with access can flip
Agently
@galdayan Sharpest question in the thread shows that you have been reading up. It's the one most tools get wrong: governance has to be recursive. A gate anyone can quietly widen isn't a gate, it's a suggestion. Our stance is that changing the rules is itself a consequential action. It should be permission-gated, logged with who changed it and when, and loosening a limit should take the same kind of sign-off as the actions it governs, not a solo Friday toggle. I won't overstate exactly where every piece is today vs on the roadmap, but this principle is non-negotiable for us, and you just described the precise failure mode we're building against. Grateful you pushed here 🙏
@omarships that's the right answer, honestly. a lot of teams treat the policy as static config instead of as another thing agents (or people) can act on, and that's exactly the gap that bites you later. good luck with the launch
@omarships @galdayan Appreciate it Gal and hope you get to try it out and see for yourself.
Agently
@galdayan Spot on brother. There is always a validation and invalidation process, nothing can happen from nothing, hence why the brain is a continuously valid source of ultimate truth for the business
Congrats on the launch, @omarships ! The bi-temporal / contradiction-at-write-time answers in this thread are more rigorous than most of what's out there. "The source's clock is a claim, not the truth" is a good line.
One thing I keep running into from the knowledge side: the brain can only reconcile what actually flows through a connector. But a lot of the highest-value context never touches a system. It's the answer someone gave in a DM, or the reason a decision got made that nobody wrote down. Does the brain have a path for capturing that, or is the bet that enough of it leaks into Slack/Linear to be inferable?
Either way, rooting for you guys 🚀
Agently
@ramsey_fahed The undocumented "why" is the moat, and no, we don't bet on it leaking into Slack. Connectors wise, we will keep expanding to capture as much context as possible outside the platform. The other way we capture context is through the use of the platform, recursively inputting data from your work into the brain. You just tell Jarvis something, and it lands as a fact with your name on it, same weight as anything a connector brings in. Better: when an agent doesn't know why, it asks. Every gap becomes a question, every answer becomes memory. The brain gets sharper the more you use it instead of dying when someone leaves.
The Stripe event to Slack thread to Linear ticket auto-linking is the interesting claim - most tools make you wire those correlations by hand. On day one, before it has any history, how does Agently decide two events across different systems belong to the same thread of work: is that learned from your data over time, or seeded from rules and shared entity IDs so it is useful immediately? And is the never-forgets memory scoped per connector, so revoking one integration also purges what it learned from that source?
Agently
@noctis06 The minute you connect the brain, it back fills data, tracking how your company has been behaving even before you ever decided to use the solution.
As for actual clean slate activation, this is probably the cleanest way to use Agently anyway. On onbaording, it asks you what your idea is, if you have a website, etc... Spins up 5 tasks to figure out your ICP, your competitors, drafts leads and gives you outreach, then the game begins.
Revoking an integrations never removes the context, it just cuts the streaming of data, context is still there.
Got it, so revoke stops the stream but the learned context stays. That's the part I'd want crystal clear before connecting a sensitive source: is there any explicit purge that actually removes what the brain inferred from a connector, say a customer invokes deletion or I offboard a tool, or is that context effectively permanent once ingested?
Huge congrats @omarships on hitting the leaderboard.. qq what's the average millisecond latency overhead between an incoming trigger event and agent execution?
Agently
@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.
ProdShort
Agently
@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."
Really interesting launch. The strongest part for me is the persistent context across tools not just another AI assistant answering prompts, but a system that can connect events and move work forward automatically.
Curious how do you keep the shared memory accurate and prevent outdated context from affecting decisions?
Congrats on the launch! 🚀
Agently
@muhammadtanveerabbas Thank you 🙏 Two layers keep it honest. The brain doesn't just stack facts, it understands state changes, so for example "churned" replaces "active" and the stale version stops driving decisions. And since nothing consequential runs without your sign-off, even if something outdated slipped through, it surfaces to you before it acts, not after. It remains a ultimate source of truth
@omarships The state-change approach makes a lot of sense. Treating memory as evolving state instead of accumulated facts is what keeps long-running workflows reliable. Curious how you handle cases where the new state is uncertain rather than definitive?
@muhammadtanveerabbas Thanks so much — really appreciate you zeroing in on the context layer, that's the part we care most about too. 🙏
On keeping shared memory accurate: a few things do the heavy lifting. Every piece of context is timestamped and tied to its source event, so nothing floats around as free-standing "facts" — it always knows where a memory came from and when. Newer signals supersede stale ones, and anything that hasn't been reinforced decays in weight rather than lingering with full authority. When two sources conflict, we surface the conflict instead of silently picking a winner, so a decision never quietly rides on outdated info.
Still plenty to sharpen here as we scale, but that's the core of how we stop old context from steering new decisions.
@muhammadtanveerabbas Mechanically it's a temporal graph: contradicting facts invalidate the old version (with a validity interval, not a delete), and retrieval favors current, provenanced context over stale. So outdated facts don't quietly leak into a decision, they're either superseded or visibly flagged as old.
@ahmadhajj The provenance layer is the standout for me. Once every memory knows its source and timestamp, it's much easier to trust the decisions built on top of it.
How often do you see conflicting sources in real-world usage? 🚀