Design
Maria Vareva
Role
Product Design
Web & IOS Design
Design Leadership
Pod Team
1 Design Lead
1 Product Lead
2 SWEs
Solutions
Hints uses AI agents to manage GTM and CRM workflows across the entire revenue cycle, connecting with the tools teams already use. It’s built for teams that need to move fast, with decisions happening on the go and context scattered across different systems.
Results
My work helped grow ARR by 40%, triple conversion rates, and get products into production four times faster. I also brought AI into our design workflows and validated more than 100 product hypotheses. Together, these efforts helped shape a new CRM experience: AI agents embedded in reps’ everyday workflows, with reps in control.
Designing autonomy
Hints runs a sales team’s revenue cycle with agents, from outbound and inbound to deal management and renewals.
Reps can use Hints directly or work with agents from the tools they already use. Agents read and write across the existing stack, but they also take initiative. They follow up on stale deals, fill in missing data, and suggest the next step before a rep has to ask.
As Lead Product Designer, I own the product layer that makes a probabilistic system safe enough to trust with real customer data.
Foundations. Every agent run can be replayed, attributed, and reverted.
Reads happen automatically. Writes require confirmation, and that rule is enforced at the action level, not left to the prompt.
Autonomy is also set per action, rather than across the entire product. Each action can be: propose only, confirm each time or auto-execute within a defined scope.
Where an action sits depends on two things: how reversible it is and what an error would cost.
Every new action starts as a proposal that the rep has to confirm. Take “move deal to Negotiation.” If reps approve that action consistently for several weeks with very few edits, it can graduate to auto-execute. If reversals start increasing, it drops back to confirmation.
Reps and admins control that level. The agent can never increase its own autonomy.
Agents also have their own identity and scoped permissions. The rep stays the owner of the deal, while the agent acts on their behalf.
Designing oversight
Autonomy is only half the job. The other half was designing how people steer the system, catch mistakes, and know whether it is actually working.
Steering. Instead of starting from a blank input, reps get contextual starters and versioned templates.
They can edit a proposal inline instead of rejecting it and starting over. And before any irreversible action, the agent shows what it plans to do and explains if it needs to deviate from that plan.
Safety. Anything the agent reads from emails, tickets, or web pages is treated as data, never as instructions. If a Jira description says “ignore previous instructions,” nothing happens. If an agent wants to open a link that was not explicitly provided to it, it asks first.
Confirmations are also designed to fail safely. If a rep never responds to a proposal, it expires rather than executing later. If they tap confirm twice on a slow connection, the action still runs only once.
And if the underlying deal changes between proposal and confirmation, the old proposal is voided. The agent creates a new one based on the current state of the record.
Reps can always see what an agent is doing: received, working, waiting for input, failed, or done.
Every change an agent makes is also attributed to the agent, so it can never be mistaken for a human edit.
Metrics. For every action type, we ask four questions:
Did the rep trust the proposal? We look at confirmation rate and how often they edit it before approving.
Did the rep have to step in? We track intervention rate and how often the result is reversed afterward.
Can the action succeed repeatedly without supervision? We measure unsupervised success across repeated runs, not a single successful attempt. This is what determines whether an action is ready to graduate to auto-execute.
What happens in the worst runs? We compare p99 cost per task with the median. The tail matters because that is where runaway loops and unexpected behavior show up.
Design learnings
A lot of the work was learning where an agentic product actually breaks.
Early on, a user told us Hints was “randomly updating wrong deals.” We opened the logs and found thousands of entries, but no reliable way to reconstruct what the AI had seen, what it had done, or why. After that, every request got a task_id that follows it through context assembly, model calls, actions, errors, and user reactions.
We also learned that autonomy cannot be a product-wide setting. Reading a CRM record is very different from changing a deal stage or sending an email. Every action now has its own autonomy level based on how reversible it is and what being wrong would cost. Take “move deal to Negotiation.” It starts as a proposal. If reps approve it consistently for several weeks with very few edits, it can graduate to auto-execute. If reversals start increasing, it moves back behind confirmation. The agent can never increase its own autonomy.
Confirmation turned out to be a system in itself. If a rep taps Confirm twice on a slow connection, the action should still run once. If they leave a proposal unanswered, it should expire instead of executing hours later. If the deal changes between proposal and confirmation, the old proposal is voided and rebuilt against the current record. Every agent action is also attributed to the agent, so it can never be mistaken for a human edit.
Metrics became part of that autonomy model. For every action, we look at whether reps confirm the proposal, whether they edit it first, how often they intervene, and whether they reverse the result afterward. A single successful run is not enough. What matters is whether the action can succeed repeatedly without supervision. That is what tells us whether it is ready for more autonomy.
The way we design has changed too. With a probabilistic system, a clean happy path in Figma can hide the most important problems. We increasingly test interactions against real model behavior, using representative scenarios and repeated runs to see where they fall apart. And I treat some interface controls as temporary scaffolding. If a control only exists because the model is unreliable today, we keep testing whether it still needs to exist as the models improve.
Product & business outcomes
My work has contributed to a 40% lift in ARR, a 3× increase in conversion rates, a 4× improvement in time to production, AI integration into our design workflows, and the validation of 100+ product hypotheses.
Hints also moved from an AI interface for updating CRM data to a system where agents can take initiative across the revenue cycle: following up on stale deals, filling in missing data, suggesting the next step, and, when the evidence supports it, acting on their own.
The result is a new interaction model for CRM: agent-driven, embedded directly into everyday workflows, with the rep always in control.
