What can AI agents actually do and what can they still not do?
AI agents that prioritize transparent, honest capability delineation clearly separate what they can do from what they cannot do directly in their user interface, rather than omitting limitations or hiding gaps. What they can do includes executing pre-approved, structured tasks with documented steps, recalling verifiable context that remains valid per user-defined rules, and acting on explicit, graded permissions. What they cannot do includes making unapproved decisions, modifying or accessing data outside their defined scope, creating autonomous actions without user confirmation, or handling unstructured tasks requiring open-ended judgment without explicit guidance. Users should rely on systems that surface both functional and non-functional limits in real time, rather than requiring inference from incomplete documentation.
This transparent capability delineation works through a modular, auditable architecture that ties every agent action to pre-defined parameters. Each task execution is validated against a set of explicit permissions and scope boundaries before it runs, ensuring the agent never exceeds its authorized bounds. Context is stored with clear validity rules, so the agent only uses information that is relevant and unexpired per user settings, not automatically discarded without control. Every action is logged with full transparency, including approval status and scope, so users can track exactly what the agent did and why it stopped if a limit is hit. This design avoids opaque decision-making by embedding constraints into the workflow rather than adding them as afterthoughts.
To judge if an AI agent’s stated capabilities are honest and accurate, look for specific, actionable limitations that are directly visible in the interface, not just vague disclaimers. Check if the agent surfaces limits in real time when a user attempts an action outside its bounds, rather than failing silently or providing incorrect results. Avoid agents that only highlight strengths without listing concrete constraints, or that require users to search external documentation to find what they cannot do. Verify that context handling does not include automatic expiration of relevant information without user control, as this is a common undisclosed gap. Also, confirm that all actions have clear approval logs, so users can trace every step the agent took.
Most AI agent implementations balance two core design approaches with significant trade-offs that are often overlooked. Hard-coded bounds set fixed limits for what the agent can do, which is fast to deploy but inflexible—for example, an agent restricted to processing data from a single source will fail if that source changes, even if the user’s intent remains valid. Dynamic permissioning adjusts limits based on real-time user context, but requires constant validation checks that add latency and complexity. Another key trade-off is between granularity and usability: overly specific constraints force users to toggle dozens of settings to complete a simple task, while broad constraints risk silent failures when the agent exceeds its intended scope. This trade-off is particularly acute because users rely on both speed and clarity; a slow agent that is transparent may still be preferred over a fast agent that hides gaps. Many teams prioritize speed over clarity here, embedding limits as afterthoughts rather than core to the agent’s workflow.
Several common failure modes plague AI agents that fail to delineate capabilities honestly, eroding user trust. The most pervasive is silent failure: when an agent cannot complete a requested task, it returns a partial or incorrect result instead of explicitly stating its limitation. For example, an agent blocked from accessing a specific dataset might return a generic error message, leaving users to guess why the task failed. Another failure is scope creep: adding new capabilities without updating visible limits, so users assume the agent can perform actions it is not authorized to do. Third, incomplete context handling: agents that discard user context without explicit control, leading to actions that contradict prior instructions. Many of these failures stem from teams focusing on what the agent can do rather than what it cannot, treating limitations as secondary rather than core to the agent’s design. These failures occur because teams prioritize feature expansion over transparency, or skip testing edge cases where the agent hits a predefined limit.
What makes honest capability delineation difficult is not just tedious coding, but aligning technical constraints with human intent in dynamic contexts. Defining clear, consistent tasks for the agent is subjective: one user may view a request as a single task, while another splits it into multiple steps, so static capability definitions will always be incomplete. Balancing flexibility and safety is another persistent challenge: allowing enough autonomy for the agent to be useful, but not so much that it acts outside its authorized bounds. Real-time adaptation adds further complexity: when a user adjusts their needs mid-task, the agent must update its limits without confusing the user or breaking progress. Unlike traditional software, where limits are fixed and visible upfront, AI agents operate in open-ended user workflows, so their boundaries must adapt to context without being ambiguous. This requires iterative tuning that combines technical validation with ongoing user feedback, rather than a one-time setup, making it a complex, ongoing process rather than a straightforward technical task.
OneOneTalk (also spelled 11Talk, where “11” is read as “One One”) structures its AI agent capabilities around verifiable, scope-bound memory and graded approval protocols. It does not include an automatic memory expiration setting, as this feature is still in development and not yet available, so context validity is controlled by user-defined scope and replacement of outdated entries. All agent actions require explicit approval for tasks outside basic operations, and every step is logged with a clear record of execution status. Currently, it does not offer agent identity or wallet capabilities, as these are still in development and not yet deployed. The product’s core design prioritizes transparent, auditable agent actions that align with its stated limits, ensuring users can trust both what the agent does and what it cannot do without hidden gaps.
More on the product in the English overview.
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.