Does Promptflow have plans to support other programming language?

[unanao]

The Semantic Kernel SDK is available in C#, Python, and Java。 Does Promptflow have plans to support other programming language， such as Java ?

[lisagreenview]

Multi programming language support in on the way, you can expect to have prompt flow C# and prompt flow JS in next few months.

[unanao]

Does Java have a specific plan?

[joechiu-uipath]

Multi programming language support in on the way, you can expect to have prompt flow C# and prompt flow JS in next few months.

Do you mean that we should be able to write tools using C# (.Net core) and javascript (running in node)?

[unanao]

Not only tools. The generated project is java/c# project

[SreedharAvvari]

Multi programming language support in on the way, you can expect to have prompt flow C# and prompt flow JS in next few months.

Is there any timeline for this support

[D-W-]

Hi @AvvariSreedhar , the C# and JS support is still working in progress. We'll update here once we have updates.

[Coding-With-Ashish]

Waiting in anticipation :)

[imranshams]

Any update for Prompt flow .Net?

[robvet]

Same question. Puzzled! Here we sit in August, without a word from the product team about expanding Prompt Flow support for mainstream development platforms. Hey, everyone loves working with Python. It's (relatively) simple to use and comes with a wide variety of libraries. However, in my role, I spend a full day working with development leadership with typically three customers each week. I'm here to tell you that the vast majority of them are NOT building enterprise application in Python, not even the AI components that Prompt Flow can produce. While their Data Science teams may use Python, the mainstream developers are not. There are several reasons as to why: Execution speed, lack of strong-typing, and so on. By not supporting .NET and Java, it would seem that Microsoft is limiting the adoption of Prompt Flow, and to some degree Azure AI Studio. Would be very interested to better understand the strategy and roadmap plans.

[Skyquek]

Any update for now?

[davicbaba]

Any status on Promptflow.NET?

[kinthaiofficial]

Language support is a real constraint for agent systems — the orchestration layer often ends up as the bottleneck because it's tied to one runtime.

A pattern we've found useful: separate the flow definition (which can be language-agnostic, expressed as a DAG in JSON/YAML) from the execution environment. Each node in the DAG can specify its own runtime — a Python agent, a TypeScript tool, a compiled Rust binary for hot paths — and the orchestrator becomes a lightweight scheduler that doesn't care about language.

The practical challenge is capability negotiation at node boundaries. When a Python orchestrator calls a TypeScript tool, you need a well-defined contract for what inputs/outputs look like, what errors mean, and crucially, what budget the called node can consume. Without that contract, cross-language flows either have opaque failure modes or require every node to re-implement cost accounting.

We standardized on a JSON schema for node capability manifests (what the node can do, what resources it needs, what it costs) that works regardless of implementation language. Inspired partly by the A2A protocol work. There's more on the architecture here: https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons

Is the multi-language request primarily for tooling/integration use cases, or for running the actual LLM orchestration logic in non-Python languages?