ash-project/ash_ai

Feature: defining tools at the resource level

Aperta

#171 aperta il 21 feb 2026

 (6 commenti) (0 reazioni) (0 assegnatari)Elixir (80 fork)auto 404
enhancementgood first issue

Metriche repository

Star
 (184 stelle)
Metriche merge PR
 (Metriche PR in attesa)

Descrizione

Code of Conduct

  • I agree to follow this project's Code of Conduct

AI Policy

  • I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

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
end

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? 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

Guida contributor