当社のエンジニアが顧客の側にいる理由と、エンジニアがそこにいない理由

どのプラットフォーム企業も最終的にはこれの何らかのバージョンを提供します。エンジニアは一定期間顧客と協力すると、他の場合よりも早く何かが構築されます。

問題は、そのエンジニアが退職したときに顧客がどのような状態になっているかであり、それはエンジニアが何のために最適化を行っていたかによって完全に異なります。

故障モード

エンジニアは物を作ります。それは機能し、顧客は満足し、それがどのように機能するかについての知識はエンジニアに委ねられます。

6 か月後、エージェントを変更する必要がありますが、内部では評価基準を理解している人は誰もおらず、顧客は独自のシステムを変更するためにサポート チケットを開きます。それは依存であり、かなり長い間、婚約が成功したかのように装うことができます。

また、短期的には商業的にも魅力的であるため、誰もそれをすべきだと決めずに頻繁に起こるのです。

私たちが実際に何をするためにそこにいるのか

エージェントの操作を機能させるための 4 つのことを、エージェントの代わりに行うのではなく、一緒に行うことで教えます。

最初に何を自動化するかを決定する方法。これは通常、顧客の直感よりも狭い選択肢です。

自分の仕事の評価基準をどのように書くか。これは最も伝わりやすく、誰も到達しないスキルです。

2 番目のエージェントが最初のエージェントの間違いを繰り返さないように、コストと所有権を計測する方法。

境界を設定し、プロンプトで説明するのではなく、アクションの時点でそれを強制する方法。

これら 4 つをうまく実行できれば、最初のエージェントの出荷は遅くなり、5 番目のエージェントは完全に彼らのものになります。

私たちが使用する尺度

エージェントが配信したものではありません。お客様が私たちなしで次のものを構築したかどうか。

これは意図的に厄介な措置です。なぜなら、成功したエンゲージメントが終了してしまうからです。私たちはこれが正しいテストであると考えており、これは弊社と協力するベンダーに適用するテストです。

エンジニアが学ぶこと

これは双方向で行われ、礼儀ではありません。私たちがプラットフォームで変更したほとんどすべては、チームが予想外の成果を上げたのを見てから生まれました。

エージェントごとのアトリビューションは、コストツールではなく在庫ツールとして使用されます。予算は厳しく設定されており、シグナルとして使用されます。事前に設計された評価基準ではなく、失敗から逆算した評価基準。これらはいずれもロードマップから生まれたものではありません。それらは誰かの隣に座ったことから来ました。

私たちがノーと言うもの

構築すべきではないと思われるものを構築する。間違っているとコストが高くつき、レビュー手順がない意思決定パスにエージェントが配置されることは、範囲の問題ではなく、設計上の異議であり、私たちはそれを提供するよりも問題を提起することを選択します。

また、当社は顧客の代理店の継続的な所有者となることもお断りします。エージェントには、それに依存する組織内に名前付きの所有者が必要です。

私たちと協力する方法

エンゲージメントには制限があり、目標は最初に述べられています。あなたのチームは私たちなしでこれを実行します。一般的な製品ではなく特定のプログラムについて話したい場合は、デモを予約し、制約事項をご持参ください。

次へ

エージェント オーケストレーション システムのページでは、この作業が構築されているレイヤーについて説明します。 「キャリア」では、これらの役割が内部からどのように見えるかを説明します。