Launching today

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










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.
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.
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.
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.
This is clever. What does Jarvis do when it can't confidently route a task to any agent?
@dhiraj_patel5 The architecture does not allow for it. The subagents are spun up based of the task that needs to be done. Jarvis injects the context into them and details the role and desired objective.
@dhiraj_patel5 Routing always resolves, because Jarvis dynamically spins up a subagent for the task instead of matching against a static set, so "no agent fits" isn't a failure state. Confidence gating lives at the subagent's actions, not the routing, high-confidence reversible work runs, anything ambiguous or consequential routes back to you.
Congrats on shipping @omarships! How do you handle messy and keep growing context?
@nicklaunches Thanks 🙏
On messy: when signals are weak or conflicting, it degrades to asking, not guessing, so bad input never becomes a confident action.
On growing: connecting sources is table stakes, but every correction and decision you make gets encoded, so it keeps getting sharper long after your stack is wired up.
@nicklaunches Messy: we link on hard signals (shared IDs/domains), and when a match is weak we flag instead of forcing it.
Growing: as more episodes land, the graph's relationship density climbs and every human correction becomes a durable signal, so the curve bends up past "everything connected." It's not just more data, it's more resolved connections.