Launched this week
Agently
Your whole stack, running itself!
552 followers
Your whole stack, running itself!
552 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.
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 🙏
FuseBase
Congrats @omarships @ahmadhajj The comments have quietly answered my biggest worry (does it ship stuff without me looking) and raised a new one (what happens when my tools disagree with each other about reality). How is conflicting data across tools resolved?
@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.
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.
@anas_chhilif Thank you 🙏 and yes, closing that loop end to end is exactly the unlock. The babysitting between tools is the tax nobody talks about. On the ambiguous next step: a good chief of staff doesn't freeze, and doesn't wing it either. They come to you with "here's what happened, here's what I'd do and why, here's the call I need from you." That's the behavior we built. When the move is obvious and reversible, Jarvis just does it. When it's genuinely a judgment call, it brings you the decision with its reasoning instead of guessing, and it gets sharper at your judgment the more it watches you make those calls. Rooting for you too 🙌
@anas_chhilif Ambiguity is confidence-gated. Every proposed next step carries a confidence signal from the brain context. High confidence + reversible, it executes. Low confidence or high stakes, it doesn't pick blindly, it generates the candidate next steps with its reasoning and routes them to you as a decision, same surface as the consequential-action gate. The part that makes it improve: it factors in how you've handled similar situations before, so "ambiguous" shrinks over time. What it'll never do is manufacture a "right" step to look autonomous. Ambiguity resolves to propose-and-defer, not guess-and-ship.
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.
@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.
@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?
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?
@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 👇
@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.
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.