PyFluent 2026: Planning Themes — An Open Discussion

[seanpearsonuk]

🧭 PyFluent 2026: Planning Themes

This thread is to collect high-level planning themes for PyFluent development in calendar year 2026.
These are early thoughts meant to seed discussion — please comment, refine, and challenge as needed.

---

I. Agentic AI Platform

1. Make PyFluent Architecture Agentic-Ready

We’ll need solid scaffolding to make Fluent a safe and robust substrate for agentic workflows.
Key enablers include:

• Error transparency: Extend the exception hierarchy to support fine-grained error handling.
• Undo/redo: Explore lightweight transaction support via get_state() snapshots around set_state().
• Constraints: Expose enums and variable descriptors programmatically (ongoing). Investigate richer runtime constraints (valid ranges, dependencies).
• Observability: Enable tracing of natural-language → PyFluent calls → Fluent actions for explainability and debugging.
• Sandboxing: Explore pseudo-sandboxing (shadow state validation in Python) as a longer-term enhancement.

2. Build an Agentic Proof-of-Concept

• Leverage the scaffolding and lessons from the LLM-Augmented Fluent PoC.
• Demonstrate autonomy: The agent should plan and execute multi-step actions rather than respond to isolated prompts.
• Initial scope: Solver setup and execution.
• Later PoCs: Extend to other stages (e.g. meshing) using specialized agents coordinated by a master agent for end-to-end workflows.
• Success criterion: Determine whether the PyFluent scaffolding adequately supports robust agentic workflows.

3. Enhance PyFluent / Fluent Robustness

• Strengthen the end-to-end architecture for reliability and transparency.
• Complete missing Settings API elements that block key workflows (high urgency).
• Improve quality and coverage of the Settings API and its documentation.
• Provide higher-level workflow primitives to reduce low-level micromanagement where appropriate.

---

II. Data Extraction Performance

Currently, solution data arrays are extracted from the Fluent solver via the cortex gRPC server.
We need to benchmark the performance of this architecture, identify bottlenecks, and design + implement improvements.

---

III. Intuitive PyFluent API

We’ve made excellent progress here — but there’s always room to go further.

• Type safety: VariableDescriptors could encode whether they apply to scalars or vectors, allowing generalized type-checking at field-data extraction interfaces.
• Completeness: Audit the VariableCatalog for completeness and fill gaps.
• Meshing usability: Continue mapping of the meshing workflow data-model naming and types to our user-friendly API surface.
• Settings API overhaul: This remains too inconsistent and under-documented.
  • Assign ownership of API sections to ACE team members for design review, documentation improvement, and example coverage.
  • Build a repeatable process for identifying and addressing problem areas.

---

💬 Discussion Prompts

• Are these themes aligned with where we should focus our 2026 efforts?
• Which of these should be highest priority?
• What other strategic themes should we consider?

---

[seanpearsonuk]

Theme IV — Componentization of PyFluent

This theme addresses a long-standing idea: to componentize PyFluent so that its core layers are modular and interchangeable.

Motivation

Currently, PyFluent’s client layer uses Fluent’s gRPC interface. We would like to introduce more flexibility here:

• Swap communication backends — for example, replacing the gRPC client layer with a REST client layer, without affecting higher-level PyFluent modules.
• Use PyFluent as a lightweight process controller — e.g., exposing only APIs for launching, monitoring, and terminating solver processes.
• Enable cross-product reuse — allowing other solvers or products to integrate into a common Python platform using PyFluent’s architecture as a foundation.

Architectural Implications

To achieve this, we’ll need to:

• Decouple PyFluent from flobject, the current Python base class underpinning Fluent’s Settings API object types.
  • flobject is too Fluent-specific to serve as a general base.
  • At the .proto level, however, the Settings API is generic and reusable, which is encouraging.
• Adopt or develop a more generic framework to replace flobject, ideally one that:
  • supports static attribute encapsulation (avoiding redundant API calls),
  • and can serve as a common base for other solvers and service layers.

Goals

• Define a component boundary for PyFluent’s transport/client layer.
• Demonstrate that PyFluent can run transparently over REST or gRPC.
• Prepare the framework for multi-solver integration within a shared Python ecosystem.

[seanpearsonuk]

@mainakk @prmukherj @hpohekar @mkundu1
@raph-luc @h-krishnan @dnwillia-work @lagacep-ans @gyeole @ansjschuetz
@cj-hodgson @millerj97 @Gobot1234
@tejalprabhu01

[Gobot1234]

In terms of enhancements to pyfluent I would really like to see 100% type coverage. I think this would really help to improve the developer experience for standalone (until pyconsole gets type checking) but would also cut down the number of bugs.

[mkundu1]

Define a component boundary for PyFluent’s transport/client layer.

A good test/sub-goal for this is to be able to use the default sessions within Fluent PyConsole without importing gRPC, SSL and other related dependencies. We've also faced issues few times in the past due to mismatch of some of these dependency versions between Fluent and PyFluent/Python.

[hpohekar]

Let’s aim for 100% test coverage to ensure maximum code reliability and maintainability. This will help us identify potential issues early, improve confidence in deployments, and uphold a high standard of software quality.

[prmukherj]

Yes, sounds good.

[raph-luc]

I would advise against chasing 100% code line coverage. It does not mean there are no bugs, it is rather misleading and not a very good metric. Having some code coverage (say more than 80% is commonly used), is okay. I think it is far more important to think about code paths and cyclomatic complexity, than specific numbers of code line coverage.

If we are looking to improve testing in PyFluent, I would say we can look into options such as mutation testing. For Python one option seems to be https://mutatest.readthedocs.io/en/latest/. I haven't used this yet, but it is something that might be worth trying out

[seanpearsonuk]

Shall we finally take the gRPC bull by the horns in 2026? Do all the things we need to do to get it fully release-ready?

[prmukherj]

I agree with this. Let's start it early on only and decide based on the status, mid-way.

[seanpearsonuk]

We have a detailed plan for this written down outside of GitHub, which I can share.

[raph-luc]

@seanpearsonuk what are you referring to, here? Do you mean in relation to Theme 4, and showing that PyFluent can work through the Rest interface as well?

[seanpearsonuk]

Some of the items in this discussion contain detailed sub-items. We should create full issues for those which we only reference from here. We can follow up on that in general discussions next week.

[raph-luc]

3. Enhance PyFluent / Fluent Robustness

• Strengthen the end-to-end architecture for reliability and transparency.
• Complete missing Settings API elements that block key workflows (high urgency).
• Improve quality and coverage of the Settings API and its documentation.

This is almost entirely server-side work, and not necessarily PyFluent, right? And yes, I can definitely see there is a lot of work that needs to be done there.

I would say this would probably be the highest priority and the most relevant part of the "Agentic" theme. Should this be its own theme? This is definitely important far beyond just agentic LLMs

[raph-luc]

Also, it looks to me like there is significant overlap in the theme list here between theme III and theme I item 3. I think could take I.3 out of there and make it part of theme III, revising theme III to be perhaps about "PyFluent and Fluent Settings API improvements", or something similar

[raph-luc]

Are the themes and points in any order of importance? Looking at these right now, if I was to attempt to rank them based on my personal opinion (and just to see what you guys are thinking as well), from most important to least important:

• I.3 Enhance PyFluent / Fluent Robustness
• III Intuitive PyFluent API
• IV Componentization of PyFluent
• II Data Extraction Performance - I imagine this might be heavily influenced by the work for theme IV
• I.1 and I.2 Agentic AI Platform - considering how things are going right now, I believe having LLMs work well with PyFluent in the long term will rely mostly on the maturity of PyFluent and the Settings API, and will not necessarily require targeted work for LLMs

Thinking aloud: I am realizing now that most of the points under "I.1 Make PyFluent Architecture Agentic-Ready" would certainly also be useful outside of LLM usage. I am thinking it might also be useful to give it more prominence as well, making that its own theme? LLM applicability of that work would be an extra benefit and extra motivation, but it something that should be done regardless

[raph-luc]

Sandboxing: Explore pseudo-sandboxing (shadow state validation in Python) as a longer-term enhancement.

I don't understand what this is trying to say. Can you elaborate or provide any examples where this is relevant in PyFluent?

I understand what variable shadowing is. But validation of it, and sandboxing? Do you mean just trying to clarify when shadowing/local scoping is occurring, and perhaps fixing it so there is no shadowing anymore, to avoid confusion?