Memory and Artefact Architectural Best Practices in Production Applications

In all the current documentation, afaik using the memory and artefact services is coupled to the agentic code base (ie you need access to the agent code to create a runner).

In a typical production scenario, I would prefer a client-server architecture. At the moment, I need my client codebase to have access to server code if I want to use artefact/memory services, which feels like an antipattern.

To spell that out, suppose I wanted to ship a client library for calling agents built with adk. If I'm using the adk memory/artefact services, then I can't do that without also shipping my 'server' agent code, which I don't want clients to have access to.

Note this is not the case for a sessions service, since in the fast api app on start up I can configure the server to connect to vertex ai session service independently of the runner by using session_db_url.

Ideally, I would be able to configure the server to use a memory and/or artefact service independently of the client. Similarly to the session service, it would make more sense to me to inject these into the fast api app constructor independently of the client code.

Alternatively, I can just write custom tools to access artefacts and/or query long term memory in any database of my choosing. Just seems a shame not to make use of the existing service code for these features.