Agently - Your whole stack, running itself!

@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.

@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.

@karimbenkeroum your the best, thanks

@karimbenkeroum Mailwarm definitely needs agently.

@dmitrii_tolstikhin The data is coming straight from stipe and slack, the brain makes correlations based on how the data relates to each other through normalization, algorithms and embedding. The brain goes through a series of processes including validation and invalidation. Jarvis does not have access to the brain to act its own. In any case, the last de-risk attempt we integrated is -> you review before it lands, you never find out from the logs, and nothing hits Stripe until you say yes. We gate before the action instead of promising undo, because you can't cleanly un-charge a customer, so billing stays in the always-approve bucket until you decide otherwise.

@dmitrii_tolstikhin Quick correction on the mechanics: ingestion, normalization, and embedding happen in the brain as a separate layer, so by the time Jarvis touches a Stripe event and a Slack thread they're already resolved into one grounded context built entirely from your source data, not stitched together at action time. Execution then sits behind an approval status no task passes without your sign-off, so even a bad read can't become a bad action, it stops at the gate.

There are such a thing as recurring tasks and skills (patterns your brain recognizes from your data then makes them into automated workflows). Those you approve and audit once under your own tolerance, then you don't need to going forward.

@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.

@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

@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.

@swati_paliwal Great question, and it's the line between a demo and something you'd actually run a team on.

Accountability is first-class: every action carries who proposed it (which agent), who approved it (which human), the reasoning, and the context it pulled from, so "who decided this and why" is never a mystery, it's on the record.

On rollback: anything reversible has a full trail and you can course-correct, but for irreversible actions we deliberately put the control before the action, not after, because you can't cleanly undo a sent email or a charge. Ahmad can walk the audit mechanics 👇

@swati_paliwal On the mechanics: every action writes an audit record with the actor (the specific agent run, or the human approver), a timestamp, the reasoning, and the exact context it pulled from the brain, all traceable end to end by correlation ID across the tools it touched. Because we approve-and-replay, the executed action is provably the one a named human signed off on, no drift between "approved" and "ran."

On rollback and reassign, I'll be precise rather than oversell: reversible actions have a trail you can act on, reassigning ownership routes through the same task/approval layer, and for irreversible side effects the real control is the pre-execution gate. We prevent instead of promising a rollback physics won't allow.

@duyk_me Appreciate you Duy

@duyk_me Thanks for the support

@himani_sah1 Great question, Himani — it's the part we obsess over most. Two separate problems, handled separately:

Accuracy — agents don't answer from vibes. Everything is grounded in your company brain (a temporal knowledge graph of your docs, CRM, Slack, tickets), and retrieval is a cited lookup — the answer points back to the actual source, and the graph knows what was true when, so stale facts don't leak in. And for anything that changes a system of record, the agent doesn't fire blindly: it produces a drafted, context-aware proposal that waits for your yes. So accuracy failures surface as "here's what I'd do" before they become actions.

Permissioning — three layers. (1) Everything is scoped to a workspace — data and connections are isolated per tenant, never shared across. (2) Tools connect via OAuth, so the agent only ever acts within the scopes you actually granted — revoke the connection and it's gone. (3) Writes go through an allowlist of validated actions, gated by a policy layer + a kill switch, and every action is logged to an audit trail. Nothing runs outside that boundary.

Short version: read broadly, cite always, and act only through a narrow, approved, audited door. Happy to go deeper on any layer 🙌

@himani_sah1 Accuracy comes from the brain, everything's grounded in your real source data, stale facts get superseded instead of lingering, and weak or conflicting signals get flagged, not guessed. Permissioning is by design, not trust: agents only get an allow-listed set of actions per tool, and anything consequential waits for your sign-off.

@alex_iliescu only one way to find out 👀