EDIT: I keep having to search for Agatha's project page: http://code.google.com/p/agatha-rrsl/
I was just trying to think of the importance for having both the RequestHandler (request objects get resolved to and handled by this) and the Processor (class that has the method that performs the action for a request... like Transaction Script pattern). The system we used to work with had these two ideas. The RequestHandler could act like an anti-corruption layer and sort of filtered out processor actions you did not expose to the outside world. Now assuming this is a more domain oriented system that represents just your core app and not any integration or externally available services, does this turn into more of a man in the middle code smell?
Could a custom piece in Agatha give you a simple anti-corruption layer? Maybe have a response factory piece that just knows how to package up an exception into a valid response object of the specific type you want. If you are using the Unit of Work pattern to wrap up each RequestHandler then you already have a place for this to go.
Now eliminating the Processors, does this mean that anytime something internally wants to call an action you have to go through Agatha again? I suppose yes if you want to reuse the transaction script for a domain action. Agatha has a way to run itself in an in-process configuration instead of a Client then a Server configuration. So you could just call right back into it and get any pre/post-RequestHandler code you had.
I'm undecided on this, so I thought I would write about it. I have to say that having the RequestHandler->Processor seems pretty smart, but the Processors ended up being small collections of actions. This resulted in, some of the time, many dependencies being needed by a Processor and not all of them needed for the specific action. That seemed like a bit of a waste and some clutter, but I would hate to have a single RequestHandler for each request (which could be 10's or 100's) then duplicate that structure again with Processors for each request just to separate out the dependencies needed to fulfill an action request.
Had another thought. You can have a shared Request/Response library for all the externally available actions to the system, but then have a non-shared library with the internal Request/Response classes. If they all inherit from the same base type and are tied into your Agatha configuration (mostly just dependency injection configuration), then you could separate out externally available and internal only actions this way. I just thought of this so it may need to bake a little longer.
Since I seem to keep mentioning it I'll include a link to Domain Model. And why not, here is a link to DTO. I'll also mention that in regards to these patterns I don't consider myself a boy with a hammer (everything's a nail mentality when you learn something new). Just trying to explore tying Agatha into a system.