Agently - Your whole stack, running itself!
by•
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.


Replies
Mailwarm
I loved the video, does it work with BYOK or your own models ?
Agently
@bengeekly I hope someone would say that. This was a placeholder video, more of an Add, the actual video didn't end up done in time.
Honest answer: today it's managed. We run on a mix of models and keep the whole system tuned around them so it just works. That's on purpose and ties straight to the "agent is the commodity" idea, the model is the layer we think you shouldn't have to babysit, so we manage it and keep it current for you. The brain, the part that's actually your moat, is 100% yours.
We have had 290 teams use it in private betas, some of which also requested opening it up to both BYOK and self hosting. Mainly enterprise for the obvious reasons, happy to have a conversation around it. DM me
Agently
@bengeekly On the eng side: today it's managed, not BYOK. The reason is reliability, we tune the agent loop, prompt caching, and tool-use behavior around specific frontier models, and swapping in an arbitrary one changes how all of that behaves. We do have per-agent model selection internally (different jobs get different models), so the plumbing for choice already exists. BYOK and self-hosted are architecturally doable and a legit enterprise/on-prem ask, we just haven't exposed them yet, because we'd rather ship one stack that's rock-solid than a dozen that mostly work. If you've got a specific model or a data-residency constraint, happy to scope it with you.
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
Agently
@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
I didn't understand much from the demo, apart from it was well made and entertaining. Can you comment on real practical examples that agently can do with precision, more the better.
Agently
@shekhar_upadhaya_1 Fair — a 60-sec demo picks "entertaining" over "exhaustive." 🙂 The short version: Agently builds a company brain from your docs, CRM, Slack, tickets, etc., then puts agents on top that take real actions in your tools — grounded in that context, so drafts and answers cite the actual source instead of guessing.
Concretely:
- Sales — spot which HubSpot deals went quiet and why, then draft personalized re-engagement in your buyers' own language.
- Support — triage an Intercom inbox and post replies grounded in your help docs.
- Eng ops — turn a Slack bug thread into a labeled, assigned Linear/Jira issue with repro steps.
- Research — "what did we decide on pricing last quarter?" → cited answer from your real Notion/Drive, not a hallucination.
- Recurring work — save any of these as a one-click private skill.
Reads across ~20 connectors (Slack, HubSpot, Notion, Intercom, Linear, Jira, GitHub, Stripe…) and writes back to many too.
Happy to run a live example on a workflow you care about — tell me your stack.
Agently
@shekhar_upadhaya_1 ill give you the answer from another pov.
The hard part for a normal assistant, and the easy part for Agently, is connecting signals across tools and moving the work forward:
• A key account's usage dips in your analytics, their champion goes quiet in Slack, and a support ticket's been open in Linear for a week. Agently connects those three into one "this account is at risk" flag, drafts outreach that references the actual open ticket, and routes it to the owner. Nobody had to notice the pattern.
• A lead fills out your form. It enriches them from the web and your brain (already in the CRM? attended a webinar? at a target account?), drafts a first reply that says why they're a fit, and routes it to the right rep, before they close the tab.
• After a customer call, it writes the recap, then actually creates the Linear tickets, assigns owners, and books the follow-up, holding anything customer-facing for your approval.
The pattern: it's not answering a prompt, it's watching your tools, connecting dots a human would miss, and moving work forward with your sign-off on anything that ships. Want me to pick one and show it live?
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?
Agently
@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.
Context.dev
HELL YEAH! Congrats on the launch!!!
Agently
@yahia_bakour3 Thanks Yahia, appreciate the support! 🙏
Agently
@yahia_bakour3 Appreciate you Yahia, one step closer to figuring out AGI. Only saying this to raise an anthropic sized round, hopefully they dont see this
Congrats on the launch! With agents acting across 100+ connectors on their own, how do you control what they're actually allowed to do, like issuing a refund, versus just flagging it for a human?
Agently
@irahimiam The key is that agents don't get root access to your tools. On every connector they get a defined, allow-listed set of actions, not free rein, so "100+ connectors" never means unbounded power across 100 systems. Within that, anything consequential like issuing a refund sits behind your approval by default: the agent flags it with its reasoning and waits, while low-risk read/draft work runs on its own. Control is by design, not by trusting the model to behave. Ahmad can go under the hood 👇
Agently
@irahimiam Mechanically it's two layers. First, capability is bounded: each provider has an action catalog that's an explicit allowlist with schema validation, so if an action isn't in the catalog, the agent can't call it, full stop. The surface across 100 connectors is defined, not open-ended. Second, within what's allowed, a policy gate classifies each call before it runs, consequential actions like refunds route to human approval by default (and you set the conditions, e.g. auto under $X), while reversible ones execute autonomously. It's enforced in the runtime, not asked of the prompt, so "issue vs flag" is a rule, not a hope.
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.
Agently
Hey Product Hunt 👋, I'm Ahmad,
Co-founder and CTO of Agently.dev
Here's what nobody warns you about when you build agents: entity resolution. The same customer shows up in Stripe, Slack, and Linear under three different names, and if your model of the company gets that wrong, everything downstream is wrong too. Agent demos are easy now. The hard part is what the agent knows.
We spent most of 8 months there: one living automated temporal knowledge graph of the whole company, kept correct enough that agents can safely write back through it. Our 100+ connectors are two-way, so agents don't just read your tools, they act back in them. Jarvis reads that graph, decides what needs doing, and dispatches agents on what it sees, not prompt by prompt.
"Do I trust the write-back" was the first question every beta cohort asked. Fair question, and parts of this are still early.
Happy to go deep on architecture, entity resolution, how Jarvis dispatches, or write-back safety. Ask away. 🛠
Agently
@ahmadhajj Building a the future for founders!
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.
Agently
@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 🙌
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.
Agently
@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 🙂
Agently
@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 🙏