Nous travaillons aux côtés de votre équipe d'implémentation pour transformer une décision humaine policy-driven en workflow agent gouverné. L'engagement n'est pas une démo ni une preuve de concept en sandbox. C'est une session de travail scopée où nous modélisons une décision production, la faisons tourner contre de vrais cas en utilisant le pattern d'adoption le plus sûr (typiquement shadow, gate ou selective routing, choisi au scoping), et mesurons le résultat contre des critères convenus ensemble.
Si les critères sont atteints, vous convertissez au contrat founding-customer et nous étendons à la décision suivante. Sinon, sortie propre, aucun engagement continu.
Knowledge est déjà opérationnel. À ce stade, la première cohorte de design partners façonne les packs, les défauts et les workflows opérateur que nous productisons ensuite. Le statut founding-partner est une conséquence de l'engagement, pas sa raison principale. La raison principale, c'est qu'une décision vous coûte quelque chose aujourd'hui.
Ce que reçoit un design partner
| Ce que vous obtenez | Détail |
|---|---|
| Protection founding-partner | Les conditions commerciales founding restent exclusives à la cohorte initiale de design partners et ne sont pas offertes comme conditions commerciales standard ensuite |
| Influence produit directe | Votre cas d'usage réel informe directement les packs, défauts et améliorations produit que nous priorisons pendant l'engagement |
| Pricing founding-customer | Prix réduit pour les douze premiers mois de production, verrouillé à la signature |
| Nommé comme founding customer | Logo sur le site (optionnel, opt-in) et un case study conjoint une fois les critères de succès atteints |
| Accès direct aux fondateurs | Session de travail hebdomadaire avec l'équipe fondatrice, plus un canal async direct pendant l'engagement |
| Développement de pack | Si votre décision n'est pas couverte par un pack existant, nous la modélisons avec votre équipe métier. Vos policies et configurations propriétaires restent les vôtres. Des patterns génériques réutilisables peuvent alimenter de futurs packs Knowledge |
Ce que nous vous demandons en retour
| Ce dont nous avons besoin | Détail |
|---|---|
| Une vraie décision production | Une décision escaladée, mal-décidée ou lente aujourd'hui, évaluée contre de vrais cas |
| Un champion business nommé et un champion tech nommé | Le champion business owne le processus et la décision — typiquement un lead Business ou Operations, parfois un head of AI product quand la décision est embarquée dans un nouveau flow agent. Le champion tech est le lead d'implémentation AI / Automation qui plombe Knowledge dans l'appelant. Compliance & Risk et Security & Platform participent quand la décision touche leur surface, mais ne sont pas les champions primaires. Une réunion de travail par semaine pendant huit semaines |
| Feedback honnête | Vous nous dites ce qui casse, ce qui est confus, ce qui manque. Nous shippons des fixes chaque semaine pendant l'engagement |
| Un engagement de huit semaines | Assez long pour que les métriques s'accumulent de manière significative. Sortie propre à la fin si nous n'avons pas atteint les critères convenus d'entrée |
| Optionnel mais apprécié | Volonté d'être cité ou référencé une fois les critères de succès atteints |
Comment se déroule l'engagement
1. Conversation de scoping. Trente minutes. Nous comprenons quelle décision fait le plus mal, si elle rentre dans la forme de Knowledge, et quel pattern d'adoption est le plus sûr pour le déploiement. Deux questions de discovery que nous posons tôt :
- Pour un parcours customer-facing — quel est votre taux de complétion actuel, et où se produisent la plupart des abandons ?
- Pour un flux d'approbation interne — combien de requêtes votre équipe review chaque mois, et quel pourcentage est approuvé sans exiger de vrai jugement ?
Les réponses à ces deux questions façonnent les critères de succès qu'on fixe pour l'engagement.
2. Proposition scopée. Sous une semaine, nous envoyons un scope écrit : la décision, le modèle, le pattern d'adoption, les critères de succès, la timeline, le pricing. Vous signez ou vous refusez. Pas de drift.
3. Kick-off (semaine 1). Nous déployons le setup Knowledge convenu et l'intégrons avec l'appelant sélectionné, dans le mode d'adoption choisi au scoping.
4. Session de travail hebdomadaire (semaines 2-8). Parcours des divergences, ajustement des règles, envoi de fixes sur Knowledge lui-même si l'engagement révèle des gaps.
5. Décision en semaine 8. Avons-nous atteint les critères convenus au scoping ? Si oui, vous convertissez au contrat founding-customer et nous étendons à la décision suivante. Sinon, sortie propre, aucun engagement continu.
Critères de succès convenus d'entrée
Avant la semaine 1, nous convenons des chiffres qui justifieraient la conversion. Critères typiques :
| Critère | Ce qu'il mesure |
|---|---|
| Accord de décision | Knowledge et votre système existant sont d'accord sur X% des cas. Divergences tracées à (a) Knowledge oubliant une règle, (b) bug legacy, ou (c) ambiguïté légitime |
| Réduction de review manuelle | Pour les cas où Knowledge marque des verdicts déterministes complets, quel % pourrait sauter la review manuelle actuelle ? |
| Délai pour livrer une règle | Entre « compliance demande une nouvelle règle » et « règle live dans Knowledge », comparé au même délai dans votre système existant |
| Efficacité de collecte | Champs demandés, requêtes de suivi et taux de complétion sur la résolution progressive de Knowledge, comparés au parcours d'onboarding ou d'intake actuel |
| Temps de reconstruction d'audit | Temps pour retrouver le contexte, les règles applicables et l'état de la policy derrière une décision historique, comparé à votre processus actuel |
| Coverage d'enforcement | Pour les engagements où un Policy Enforcement Point est déployé (décorateur SDK, intercepteur MCP, wrapper custom) : part des actions automatisées qui exigent un verdict signé valide avant de s'exécuter |
Amenez votre équipe AI interne ou votre partenaire d'implémentation
Knowledge ne construit pas l'agent pour vous. L'engagement présuppose une équipe d'implémentation — soit votre équipe AI / automation interne, soit un partenaire d'implémentation (SI, agent vendor, cabinet boutique) déjà engagé sur le projet. Nous travaillons à leurs côtés pour transformer une décision humaine policy-driven en workflow agent gouverné.
Si vous n'avez pas encore d'équipe d'implémentation en place, nous pouvons vous introduire à des partenaires avec lesquels nous avons déjà livré. C'est une discussion, pas un marketplace ; l'intention est de s'assurer que le premier engagement a les bonnes mains, pas de vous router à travers un canal.
Voir Construire des agents rule-governed si vous êtes le partenaire d'implémentation.
L'engagement en une image
Votre équipe + SMEs
|
v
formaliser les règles
|
v
Knowledge
|
v
replay historique
|
v
déploiement shadow
|
v
mesurer
|
v
production si les chiffres tombent
Pourquoi trois seulement
Engagements hands-on avec implication directe des fondateurs et de l'équipe produit. Nous limitons la première cohorte à trois firmes pour que chaque partenaire puisse influencer matériellement ce qui est productisé, et pour que nous puissions shipper des fixes hebdomadaires qui répondent à ce que les engagements révèlent. Le fit est déterminé par la décision et le problème, pas par le label sectoriel.