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.
Mailwarm
I loved the video, does it work with BYOK or your own models ?
@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
@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.
Hey Product Hunt 👋,
I'm Omar, founder of Agently.dev.
Here's the bet I'd stake the company on: one person should be able to run a whole company without being its memory, and a small team should ship like a big one. That only happens if the agent stops being the product. The agent is the commodity. The brain is the product.
Most agents are stateless: grab data, do a task, forget. Fancy macros. Ours runs on a persistent, entity-resolved model of your whole company, what each thing is, why it matters, when it's relevant, how it connects, across every tool, never forgetting. A living graph, not a chat history, so work lands instead of waiting on you.
Jarvis reads that brain, decides what needs doing, and dispatches event-triggered agents that act back through 100+ two-way connectors, so the work closes instead of piling on you: triggered, running, shipped. Real artifacts, not summaries. The hard part everyone stops at is keeping that model live, correct, and safe to write back through.
It compounds. Months in, your brain knows your company in a way even your co-founder cant, and you come off the critical path. That's the moat.
The teams already running on it go from solo founders to enterprises. This is where work is going. Become part of the future. 🧠
Learnetto
@omarships Looks super cool. Will give it a try!
@hrishio Looking forward to your feedback. In our vibe building era
@omarships Super excited for this launch. First company of its kind
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. 🛠
@ahmadhajj Building a the future for founders!
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
EverTutor AI
Congrats on the launch, Omar and team! 🚀 The idea of having an AI chief of staff that keeps your entire company context and actually gets work done across tools is incredibly exciting. Building something this ambitious isn't easy, and it's great to see you pushing the boundaries of what's possible with AI agents. Wishing you an amazing Product Hunt day and can't wait to see where Agently goes from here! 🙌🔥
@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.
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.
This hits a real pain point. Most "AI ops" tools still make you babysit the handoffs, Stripe fires an event, you check Slack, you manually open a Linear ticket. If Jarvis actually closes that loop end to end, that's the unlock. Curious how it handles edge cases where the "right" next step isn't obvious. Congrats on the launch, rooting for you.