Prostir

Tech

Plateforme IA cloud-native. Sur du .NET d'entreprise, dès le premier jour.

Le prompt est la partie facile. L'identité, l'état, l'accès, les opérations et un endpoint public stable demandent davantage. Prostir construit ces frontières sur .NET 10, Orleans, Aspire et Microsoft Agent Framework.

5surfaces produit principales

Agent, Skill, Flow, Team et Store gardent des identités et cycles de vie distincts.

14langues prises en charge

La landing statique publie routes et métadonnées explicites pour chaque locale non russe prise en charge.

10couches d'architecture

Du runtime compilé et des ressources cloud jusqu'à la surface publique statique.

1endpoint MCP par Agent publié

Chaque Agent publié expose son endpoint Streamable HTTP lié au slug.

Le parcours

Votre idée tient en un prompt. La production tient en dix couches d'entreprise.

Toutes les démos d'IA se ressemblent dans ChatGPT. Le vrai écart est entre cette démo et un client qui continue de payer, et c'est là que la plupart des équipes calent. Voici donc la nôtre, du sol compilé jusqu'à l'URL publique. Dix couches. Chacune est le choix prudent et fiable. Chacune est une raison pour qu'une personne sans code puisse livrer un vrai produit.

  1. 01Les fondations

    .NET 10 et C# : une base compilée et typée.

    Prostir utilise .NET 10 et C# 14 pour les contrats typés, l'I/O asynchrone, dependency injection, options, télémétrie, HTTP hosting, services en arrière-plan et source generation. Le langage seul ne garantit ni coût, ni performance, ni énergie, ni sécurité de la supply chain : ces résultats dépendent de la charge, des dépendances, du déploiement et de l'exploitation.

    • net10.0
    • ASP.NET Core 10
    • C# 14
    • Source generators
    • Typed contracts
  2. 02Le cloud

    Azure : services managés et frontières de déploiement explicites.

    Prostir utilise Azure Container Apps, Cosmos DB Serverless, Blob Storage, Monitor, managed identity et RBAC. Azure publie des documents de conformité et des conditions de disponibilité par service ; ils ne certifient pas automatiquement Prostir et ne créent pas de SLA global du produit. Les régions et ressources sont définies par l'environnement opérateur.

    • Azure Container Apps
    • Cosmos DB Serverless
    • Azure Blob Storage
    • Azure Monitor
    • Managed identity + RBAC
  3. 03Le pont local

    Aspire : un AppHost et un câblage d'intégration.

    Prostir.AppHost compose Cosmos DB, Azure Storage, Orleans, API, Gateway, WebApp, Landing et SuperAdmin pour les flux locaux et les tests d'intégration. Cela aide à repérer les écarts de configuration ; la readiness production demande encore validation du déploiement, monitoring et contrôles de release.

    • Aspire AppHost SDK
    • Aspire.Hosting.Azure.CosmosDB
    • Aspire.Hosting.Azure.Storage
    • Aspire.Hosting.Orleans
    • TUnit.Aspire
  4. 04Le runtime distribué

    Orleans : chaque agent a un jumeau numérique.

    Voici l'idée qui rend tout le reste simple. Orleans donne à chaque agent un acteur virtuel. Voyez-le comme un jumeau numérique : une copie logicielle d'une chose réelle, un agent, un client, qui garde sa propre mémoire et fait son propre travail dans sa pièce fermée à lui, sans que personne d'autre n'y touche. Une fois que tout est un jumeau, le travail ne porte plus sur des serveurs mais sur des objets qui se parlent. Vous décrivez juste qui envoie quel message à qui : une personne à un jumeau, un jumeau à un autre jumeau. C'est tout le modèle. Il est ancien et éprouvé. Erlang a fait tourner des réseaux téléphoniques comme ça pendant des décennies presque sans interruption. Orleans s'occupe des parties difficiles, comme l'endroit où vit chaque jumeau et la façon dont sa mémoire est sauvegardée et déplacée entre les machines. La montée en charge n'est donc jamais une astuce de cache fragile. C'est un jumeau sûr et isolé pour chaque chose qui compte.

    • Microsoft.Orleans.Server 10.2.2
    • ManagedCode.Orleans.SignalR
    • ManagedCode.Orleans.Identity
    • Cosmos persistence
    • Grain-owned state
  5. 05La frontière MCP

    ManagedCode.MCPGateway : du MCP distant qui passe à l'échelle.

    La spec MCP décrit un protocole. Elle ne décrit pas les connexions multi-clients, les journaux d'audit, les plafonds de coût ni les limites d'usage, c'est-à-dire exactement ce dont un déploiement réel a besoin. ManagedCode.MCPGateway est la couche d'entrée que Managed Code a écrite pour que Prostir n'ait pas à le faire. Elle gère le transport sécurisé, l'accès par client, les limites par outil et les réponses d'erreur propres, le tout devant le runtime Orleans vers lequel elle achemine les appels. Une seule URL propre et protégée fait face au monde.

    • ManagedCode.MCPGateway 0.4.5
    • ModelContextProtocol 1.4.1
    • Streamable HTTP
    • OAuth + PKCE
    • Bounded quotas
  6. 06La couche de connaissance

    ManagedCode.MarkdownLd.Kb : contexte source interrogeable.

    ManagedCode.MarkdownLd.Kb transforme les sources prises en charge en artefacts Markdown-LD ou JSON-LD et en graphe interrogeable. JsonSchema.Net valide les arguments des outils MCP. La recherche peut renvoyer un contexte lié à la source lorsque l'index le permet ; qualité et citations dépendent toujours des sources, de l'indexation, de la configuration et du modèle.

    • ManagedCode.MarkdownLd.Kb 0.2.7
    • ManagedCode.Storage.Azure
    • JsonSchema.Net 9.3
    • PdfPig + OpenXml
    • Graph-backed retrieval
  7. 07Le cerveau IA

    Une frontière applicative pour les modèles configurés.

    Microsoft.Extensions.AI fournit IChatClient et Microsoft Agent Framework exécute les Agents prompt et déclaratifs. Les routes actuelles utilisent Azure OpenAI, des fournisseurs OpenAI-compatible ou les connexions du créateur. Disponibilité et changement de modèle dépendent de la configuration, des capacités compatibles, des identifiants et de la politique produit.

    • Microsoft.Extensions.AI
    • Microsoft.Agents.AI 1.15
    • Azure OpenAI + OpenAI-compatible
    • Prompt + declarative workflows
    • IChatClient middleware
  8. 08La boucle de développement

    Développement assisté par agents avec des règles visibles.

    Prostir utilise les règles AGENTS.md, les vertical slices, la code review, les contrôles ciblés, les tests d'intégration et les gates de release. Les coding agents assistent la recherche, l'implémentation et la revue sans remplacer l'ownership, le jugement humain ni la vérification.

    Claude CodeOpenAI Codex
    • AI-assisted delivery
    • AGENTS.md rules
    • Vertical slices
    • Human-reviewed changes
    • Integration test gates
  9. 09La face produit

    Blazor, Stripe and Rozetka Pay, Stateless, Jint : la surface côté créateur.

    Le créateur ne voit jamais la passerelle. Il voit un espace de travail Blazor. L'opérateur ne voit jamais la carte des grains. Il voit une console en Blazor Server. Stateless met des rails sur une conversation. L'agent est toujours dans un état, et l'état décide de ce qui peut arriver ensuite. Mettez-la dans un état « rassembler les détails » et elle ne sautera pas à « donner la réponse » tant que les détails ne sont pas là, exactement comme vous n'enverriez pas un devis avant d'avoir entendu ce dont le client a besoin. Jint exécute de petits bouts de JavaScript dans un bac à sable quand un outil a besoin d'un nombre exact. Stripe and Rozetka Pay integration transforme l'accès payant en vraies permissions, avec webhooks, checkout et limites d'usage. Cette couche produit sans éclat, c'est elle qui rend l'IA utilisable, et vendable.

    • Blazor WebAssembly 10
    • MudBlazor 9.7
    • Stripe and Rozetka Pay integration + webhooks
    • Stateless state machines
    • Jint 4 sandbox
  10. 10La vitrine statique

    Une landing Astro avec des métadonnées de découverte explicites.

    La page est générée en HTML statique par Astro. Canonical links, hreflang, données structurées, sitemap, IndexNow et llms.txt décrivent les routes publiques prévues. Les contrôles locaux couvrent HTML, crawlability, accessibilité et templates Lighthouse ; les moteurs de recherche décident du crawl, de l'indexation et du classement.

    • Astro static landing
    • JSON-LD + sitemap
    • IndexNow + llms.txt
    • Local Lighthouse checks
    • Localized hreflang

Le résultat

Un endpoint MCP hébergé, observable et vendable par agent.

Les couches se rejoignent dans une URL MCP liée au slug de chaque Agent publié. Les clients pris en charge peuvent se connecter à l'endpoint Streamable HTTP ; accès, facturation, connaissance, outils, état, mémoire, audit et limites restent des capacités explicites activées par configuration et entitlement.

  • Remote MCP endpoint
  • OAuth 2.1 + entitlements
  • Per-agent quotas + audit
  • Live operator visibility

Pourquoi .NET

Trois stacks viables, un choix Prostir documenté.

Node.js, Python et .NET peuvent héberger des serveurs MCP. Le tableau décrit les choix de Prostir, pas un classement universel de performance, coût, énergie ou sécurité.

CapacitéNode.js / ExpressPython / FastAPIProstir (.NET 10)
Runtime HTTPNode.js runtimePython ASGI runtimeASP.NET Core 10
État distribué par identitéChoose a state frameworkChoose a state frameworkOrleans 10.2.2 virtual actors
Dependency injection, options et télémétrieFramework or library choiceFramework or library choiceMicrosoft.Extensions.*
Abstraction IAProvider libraries or abstractionProvider libraries or abstractionMicrosoft.Extensions.AI + Agent Framework 1.15
SDK MCPOfficial MCP TypeScript SDKOfficial MCP Python SDKOfficial MCP C# SDK 1.4.1
Validation des schémas d'outilsLibrary-selected validationLibrary-selected validationJsonSchema.Net 9.3
Modèle de contratsTypeScript contractsPython typing toolsC# 14 + source generation
Composition localeLocal process toolingLocal process toolingdotnet watch + Aspire AppHost

Les colonnes Node.js et Python indiquent des choix courants, pas des limites. La colonne Prostir est vérifiée dans les package et project files actuels.

Pourquoi Azure

Même backend MCP. Pensé pour le cloud où il tourne.

Pas une grille tarifaire, une grille d'adéquation. Voici ce dont un backend MCP payant et multi-client a vraiment besoin, et où chaque élément se pose mieux sur Azure. AWS est excellent. C'est juste là que le produit se pose.

Ce qui compteSur AWSProstir sur Azure
Éléments de contrôle et conformitéService-specific controls and certificationsAzure service controls; Prostir deployment assessed separately
Conditions de disponibilitéPer-service and per-region termsNo blanket Prostir SLA is claimed here
Placement régionalRegion configured per workloadOperator-provisioned regional resources
Réseau et ingressOptional global networking servicesConfigured Gateway and static-site routing
Routes de fournisseurs de modèlesBedrock and partner model routesAzure OpenAI, OpenAI-compatible, and creator BYOK routes
Accès clientCognito or custom identityProstir access and OAuth policy above the hosting layer
Runtime applicatifRuntime selected by the team.NET, Orleans, Aspire, and Managed Code libraries
Hébergement de la landing statiqueS3 + CloudFront or AmplifyAzure Static Web Apps for this landing

Les fournisseurs cloud documentent leurs services. Certification, SLA, régions et contrôles opérationnels de Prostir doivent être vérifiés séparément pour l'environnement réel.

Open source

L'open source qu'on livre, l'open source qu'on utilise.

Prostir est construit par Managed Code sur de l'open source Microsoft et communautaire. Chaque paquet ci-dessous est réel, tiré des fichiers de notre projet, pas une liste de souhaits marketing.

01

Construit par Managed Code

Managed Code n'est pas juste le crédit en pied de page. La passerelle MCP, le pipeline de connaissance, le stockage et les intégrations Orleans sous votre agent publié sont de l'open source Managed Code qu'on maintient et qu'on livre.

02

Les fondations .NET

Tout ce que Microsoft fait passer en GA depuis .NET 6 s'est rejoint dans .NET 10 et Aspire. C'est la plomberie sans éclat et fiable sous chaque page de Prostir.

03

IA, MCP et les bibliothèques au-dessus

Prostir utilise Microsoft.Extensions.AI comme frontière chat et Microsoft Agent Framework 1.15 pour exécuter les Agents. Le runtime utilise aussi le SDK MCP C# 1.4.1, Jint, Stateless et les intégrations Stripe et Rozetka Pay pour les parcours pris en charge.

04

Comment ce site est construit et livré

Prostir utilise le développement assisté par agents avec des règles de dépôt, la code review, des contrôles automatisés et un ownership humain. AGENTS.md rend le contrat de livraison visible et Astro génère cette page statique localisée.

FAQ tech

Les questions que les équipes posent avant de bâtir sur cette stack.

Ces réponses relient la stack à de vraies décisions de production : Orleans, Aspire, C#, MCP, facturation, accès, connaissance et visibilité opérateur.

Quel travail réel Orleans fait-il dans Prostir ?Orleans possède les identités runtime qui vivent longtemps : agents, sessions, clients, access grants, conversations de canaux, réservations de wallet et exécutions de workflow. Chacune a un id stable, un état et un comportement, au lieu de cacher l'état dans un singleton, un cache ou un processus de fond.Lire
Quand Orleans vaut-il mieux qu'une queue plus une API CRUD ?Quand vous avez beaucoup de petites entités assez indépendantes qui ont besoin de request-response, de flux start-monitor-complete ou d'état par identité. Microsoft cite user profiles, purchase orders, sessions, stocks et social pub/sub ; Prostir applique ce modèle aux agents, sessions client et workflow runs.Lire
Qu'est-ce qu'un grain, côté produit ?Un grain est un acteur virtuel : un objet logique avec une identité, un comportement et, si besoin, un état persistant. Dans Prostir, cela peut être un agent publié, une conversation client, un access grant ou une exécution de workflow.Lire
Comment Orleans aide-t-il l'isolation des clients ?L'état est cléé par owner, agent, customer ou run identity, donc le travail tombe naturellement dans des grains isolés plutôt que dans la mémoire partagée du processus. Une session en échec ne devient pas un état mutable global pour tous les autres tenants.Lire
Quels sont les principaux risques avec Orleans ?Les risques sont les grains trop bavards, un coordinateur qui devient goulot, les appels synchrones bloquants, les messages trop gros et l'état partagé caché. Prostir les garde visibles avec ownership vertical, appels async, stateless workers pour le fan-out et tests d'intégration sur le vrai chemin Gateway/API/Orleans.Lire
Qu'est-ce qu'Aspire ajoute à Docker Compose ?Aspire donne à la solution .NET un AppHost qui connaît projets, dépendances, service discovery, configuration, health, télémétrie et ressources cloud. Ce n'est pas seulement du démarrage de processus ; c'est le graphe de ressources pour local, CI et Azure.Lire
Comment Prostir utilise Aspire dans les tests ?L'AppHost démarre les ressources nécessaires aux tests d'intégration et navigateur, dont Cosmos DB, Azure Storage, Orleans, API, Gateway, Landing, WebApp et SuperAdmin. Cela exerce les mêmes frontières de service ; la production garde une configuration et des contrôles de release propres au déploiement.Lire
Pourquoi le runtime est-il en C# et .NET ?Le runtime a besoin de contrats forts, async IO, dependency injection, options, télémétrie, HTTP hosting, background workers, source generation et déploiements prévisibles. .NET fournit cela comme infrastructure first-party, pas comme un collage de paquets sans lien.Lire
.NET enferme-t-il Prostir chez un seul fournisseur IA ?Non. Microsoft.Extensions.AI et `IChatClient` fournissent une frontière stable pour chat et tools. Le modèle concret vient d'une connexion Azure OpenAI, OpenAI-compatible ou du créateur qui respecte le contrat runtime.Lire
Pourquoi MCP est-il difficile en production ?Le protocole n'est que l'entrée. Un endpoint MCP distant payant a aussi besoin d'OAuth, access grants, tenant checks, tool schemas, rate limits, quotas, facturation, audit, erreurs fiables et d'un hot path qui ne relit pas toute la base produit à chaque request.Lire
Où se place ManagedCode.MCPGateway ?ManagedCode.MCPGateway est la frontière protocole devant le runtime Orleans. Il expose l'endpoint MCP distant, route les tool calls, applique les limites visibles des outils et garde les sujets protocole hors de l'API d'état produit.Lire
Comment l'accès payé devient-il une permission runtime ?Checkout et webhooks des providers du vendeur créent ou révoquent des access grants. Gateway vérifie ces grants avant les appels MCP protégés, donc l'état de paiement devient une permission runtime, pas une feuille de calcul.Lire
Comment la couche connaissance évite-t-elle le prompt stuffing ?Les fichiers deviennent des artefacts Markdown-LD / JSON-LD et des graphes consultables. Le runtime récupère un contexte borné et relié aux sources quand l'index le permet ; la qualité dépend des sources, de l'indexation, de la configuration et du modèle.Lire
Quels cas réels correspondent à cette stack ?Les bons cas : agents de connaissance payants, copilotes support avec mémoire client, process agents avec state machines, agents de canal pour Telegram ou web widgets, skill passports vendables et workflows qui ont besoin de progression, retries et audit.Lire
Quand cette stack est-elle trop lourde ?Si vous avez seulement besoin d'un site statique, d'une démo de prompt ou d'un chatbot privé sans auth, tools, billing, state ni customer memory, prenez plus simple. Prostir existe quand l'agent devient un produit hébergé dont d'autres dépendent.Lire
Prostir fonctionne-t-il par API ou par MCP ?Pour utiliser un Agent dans Claude, ChatGPT et d'autres clients compatibles, le parcours passe par son endpoint MCP distant. Prostir utilise aussi des APIs et webhooks pour la gestion web, les paiements et les intégrations approuvées. La plateforme est hébergée sur .NET et Azure ; connecter un CRM, une base de données ou un système privé dépend du plan et peut demander un périmètre sur mesure.Lire

Tech

Reliez la technologie à un parcours produit concret.

Les guides et exemples montrent où comptent connaissance, outils, état, mémoire, facturation, accès, quotas et visibilité opérateur. Les cas clients vérifiés restent une catégorie distincte.