The most important decision when you build an agent isn't what you let it do. It's what you stop it from deciding.
I learned this building a system that prioritizes development tickets from ContentSquare data. On paper, ranked by numbers. In practice, prioritization is a business decision — and that boundary has to be designed on purpose.
View on LinkedInThe most important decision when you build an agent isn't what you let it do. It's what you stop it from deciding.
I got there building the system that prioritizes development tickets in my workflow.
The agent reads user behavior data from ContentSquare, crosses problem frequency with friction sessions, looks at the technical severity of each issue, and from that builds a list of what to tackle first.
On paper it's perfect. A priority order based on numbers — no opinions, no meetings.
A high number isn't a high priority
A problem that touches many sessions can matter less than one that touches few. An issue with low technical severity can be the one blocking a campaign already planned.
That context the agent doesn't have. And it shouldn't.
Because the moment the agent ranks priorities and opens tickets, it has already made a business decision. Silently. Disguised as a task that looks technical.
Prioritizing isn't reading the data. It's deciding what matters more. And that choice belongs to whoever knows the business — not to whoever reads the metrics.
I redesigned the system around a clear boundary
The agent no longer opens anything on its own. It builds a plan.
- It collects the data and proposes a priority order
- It hands the plan to a second agent that does one thing only: review it and apply prioritization logic based on business rules defined by the team
- The plan reaches a human reviewer
- Without confirmation, not a single ticket is opened
The repetitive work stays automated. The decision stays human.
I didn't take power away from the agent out of distrust. I did it because an agent that decides what matters most is doing a job that isn't its job.
The question worth asking
The right question when you design an automation isn't “what can this agent do.” It's “where does what it can propose end — and where does what a person must decide begin.”
That boundary is the most important part to design. And it's also the easiest to forget — because when the agent works well, you don't notice it's deciding. You only notice when it decided wrong.
In your team, which decisions have you let slip into an automation without really deciding to?
Takeaway
Automate collection, synthesis, and proposals. Gate anything that encodes business priority behind human confirmation. If the agent can open work without that gate, it's already deciding what counts.
