feat: class-based agents `input_*` syntax sugar

[dazy-ds]

Feature description

Enable developers to define input_* fields directly in an Agent subclass, which would automatically be converted into a PromptInput model with runtime validation and (ideally) static type safety. This would allow inputs to be defined as typed attributes (e.g., input_location: str) and seamlessly transformed into a Pydantic model, ensuring both runtime correctness and better developer ergonomics. Example usage:

class WeatherAgent(Agent):
    """
    Agent that returns weather for a given location.
    """

    system_prompt = """
    You are a helpful assistant that responds to user questions about weather.
    """
    user_prompt = """
    Tell me the temperature in {{ location }}.
    """
    input_location: str

would automatically generate WeatherAgent.input_type(location: str) with autocomplete support and type checking, so that agent.run() accepts only properly structured inputs.

Motivation

The current workflow requires manual definition of input schemas, which can feel redundant and error-prone. Allowing input fields to be declared as typed class attributes makes the API more intuitive and reduces boilerplate.

• Autocomplete in IDEs for generated input methods (agent.input_type(...)).
• Type safety enforced by MyPy, preventing accidental misuse of input structures.
• Runtime validation using Pydantic models, ensuring input correctness even if static analysis is bypassed.

This balances developer productivity, correctness, and maintainability.

Additional context

Implementing this feature poses significant challenges due to limitations of Python’s type system and tooling ecosystem:

• MyPy and IDEs rely on static code analysis, not runtime-generated classes. Since the input model would be dynamically constructed from annotated attributes at runtime, most IDEs and MyPy will not infer correct types automatically.

• Trade-offs are required:

  • Sacrificing IDE type hints in the run() method but preserving runtime validation with Pydantic.
  • Writing and maintaining a custom MyPy plugin that understands and processes input_* fields at static-check time. This would provide the desired static guarantees, but comes with overhead: building, maintaining, and distributing the plugin, as well as requiring users to configure it in their MyPy setup.

• Autocomplete remains limited in editors like PyCharm and VSCode, which generally don’t “see” dynamically generated attributes. Only a custom plugin or code-generation step could provide true IDE support.

In short, while the feature improves ergonomics and safety at runtime, achieving robust static type support may not be possible without heavy tooling investment.