Code of Conduct
AI Policy
Is your feature request related to a problem? Please describe.
Tools can only be defined at the domain level, which means tool definitions live far from the actions and policies they relate to. When working on a resource, you have to look at two separate files to understand what's exposed as a tool and how the action is defined.
Describe the solution you'd like
Support tools do block on resources directly, similar to how code_interface supports both domain and resource level definitions. since the resource is implicit, the resource argument could be left out.
defmodule MyApp.HR.Employee do
use Ash.Resource,
domain: MyApp.HR,
authorizers: [Ash.Policy.Authorizer],
extensions: [AshGrant, AshAi]
ash_grant do
resolver MyApp.PermissionResolver
default_policies true
default_field_policies true
scope :all, true
scope :same_department, expr(department_id == ^actor(:department_id))
scope :own, expr(id == ^actor(:employee_id))
field_group :public, [:name, :department, :position, :office_location]
field_group :hr_basic, [:public], [:phone, :email, :hire_date]
field_group :payroll, [:hr_basic], [:salary, :bank_account, :tax_id]
end
tools do
tool :search_employees, :read
tool :update_employee, :update, identity: :id
end
actions do
read :read do
description "Search employees by name, department, or position"
end
update :update do
accept [:phone, :office_location, :department_id]
description "Update employee information"
end
end
endAn AI agent used be HR gets tools, action, scopes, field-level visibility, and authorization all defined in one place.
Describe alternatives you've considered
Adding a flag like expose_as_tool? true directly on the action would be the simplest option, but per Zach's feedback on Discord, entities (actions/attributes) aren't currently extensible with custom properties.
Additional context
No response
Code of Conduct
AI Policy
Is your feature request related to a problem? Please describe.
Tools can only be defined at the domain level, which means tool definitions live far from the actions and policies they relate to. When working on a resource, you have to look at two separate files to understand what's exposed as a tool and how the action is defined.
Describe the solution you'd like
Support
tools doblock on resources directly, similar to howcode_interfacesupports both domain and resource level definitions. since the resource is implicit, theresourceargument could be left out.An AI agent used be HR gets tools, action, scopes, field-level visibility, and authorization all defined in one place.
Describe alternatives you've considered
Adding a flag like
expose_as_tool? truedirectly on the action would be the simplest option, but per Zach's feedback on Discord, entities (actions/attributes) aren't currently extensible with custom properties.Additional context
No response