Agent architecture

[halcwb]

Is your feature request related to a problem? Please describe.
Currently the core domain libraries offer an Api.fs to make use of their services.

Describe the solution you'd like
Use a Mailboxprocessor approach where the Api is offered as a Command DU type. This can mirror the Client Server approach that is used by the communication between Informedica.GenPRES.Server and Informedica.GenPRES.Client.

This approach also works great for:

• Async communication
• Extending the Command DU with additional cases when needed
• Offering a clear audit trail as each Command call fits nicely with an Event sourcing

So, there needs to be a Command -> Response pattern throughout the solution with a consistent architecture.

Note that this would only apply to libraries that offer a domain specific service, so, the following libraries should be excluded from this approach:

Informedica.Agents.Lib
Informedica.Logging.Lib
Informedica.Utils.Lib
Informedica.GenCORE.Lib
Informedica.GenPRES.Shared and Server and Client
Informedica.GenSOLVER.Lib
Informedica.GenUNITS.Lib

Start with

• Informedica.ZForm.Lib/Informedica.ZIndex.Lib
• Informedica.GenFORM.Lib and
• Informedica.GenORDER.Lib

First create an architectural design. Look for appropriate libraries to facilitate this Agen like architecture.

[halcwb]

/repo-assist.

Greptile Summary
This PR introduces an architectural design document and four .fsx demonstration scripts (excluded from review per coding standards) that establish a consistent Command → Response pattern for the GenPRES domain libraries (ZIndex.Lib, ZForm.Lib, GenFORM.Lib, GenORDER.Lib), built on the existing Informedica.Agents.Lib MailboxProcessor infrastructure and mirroring the top-level IServerApi.processCommand pattern already used in the Server/Client layer.

The design is well-reasoned — it correctly identifies that OrderContext.Command already exists, that no new NuGet packages are needed, and that GenORDER.Lib gets Agents.Lib for free transitively. However, three issues in the illustrative code should be addressed before migration:

Audit-log wrapper timeout risk: The auditedAgent calls Agent.postAndReply synchronously inside a MailboxProcessor message handler. The actual Agent.postAndReply implementation has a hardcoded 1-second timeout — long-running operations (cache reload, complex rule filtering) will fail to reply, leaving callers blocked.
ReloadCache unhandled exceptions: The handler performs I/O without a try/catch. Any exception thrown will prevent replyChannel.Reply from being called, causing callers to hang. All I/O-performing handlers should wrap in try/with and return Response.Error.
FilterDoseRules always wraps in Ok: The response variant is typed Result<DoseRule array, Message list> but the handler always wraps in Ok, which either masks errors or signals the response type should be simplified — the design should clarify which.
Confidence Score: 3/5
Safe to merge as a documentation PR, but the illustrative code snippets should be corrected before they are used as implementation blueprints.
The document is a design artefact, not production code, so no runtime breakage is introduced. However, two of the three issues (blocking timeout in audit wrapper, unhandled exceptions in ReloadCache) are real bugs that would manifest if the snippets are copied verbatim during the migration step — hence a score of 3 rather than 4 or 5.
docs/mdr/design-history/agent-architecture.md — the auditedAgent, ReloadCache handler, and FilterDoseRules handler snippets all need corrections before being used as implementation reference.

[github-actions]

🤖 This is an automated response from Repo Assist.

The architectural design document has been merged via PR #177 — great foundation! The Greeptile analysis in the comment above identifies three concrete issues in the code snippets that should be addressed before the migration scripts are written, to avoid propagating bugs into implementation:

1. Audit-log wrapper: synchronous postAndReply timeout

Inside a MailboxProcessor handler, calling Agent.postAndReply blocks the mailbox. If the inner agent takes longer than the hardcoded 1-second timeout it will throw, leaving the outer replyChannel unanswered and callers hung indefinitely.

Fix: replace the synchronous call with Agent.postAndAsyncReply in the handler, or move audit logging to fire-and-forget (Agent.post) so it never blocks the reply path:

// ✅ fire-and-forget: never blocks
auditAgent |> Agent.post (cmd, response)
replyChannel.Reply response

2. ReloadCache: I/O without exception handling

If loadData() throws, replyChannel.Reply is never called and the caller hangs.

Fix: wrap I/O in try/with and always reply:

| ReloadCache replyChannel ->
    let response =
        try
            let data = loadData ()
            state <- data
            Response.Ok ()
        with ex ->
            Response.Error [ Message.create ex.Message ]
    replyChannel.Reply response
    return state

3. FilterDoseRules return type mismatch

The response is typed Result(DoseRule array, Message list) but the handler always returns Ok, making the error case unreachable. Either narrow the return type to DoseRule array, or plumb actual error propagation.

---

These are all straightforward fixes. I'd suggest updating docs/mdr/design-history/agent-architecture.md with the corrected snippets so the document serves as a reliable implementation reference. Happy to submit a follow-up PR for the doc if that would help.

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@f2c5cf1e4af58e09a93ba0703c6bf084711b265f