Ampersand may $15M—legacy CRM ang bagong harang sa AI agents

|May-akda: QUASA Editorial Team|5 minutong pagbasa
Ampersand may $15M—legacy CRM ang bagong harang sa AI agents

Noong Oktubre 6, 2026, inanunsiyo ng Ampersand sa San Francisco ang $15M Series A na pinangunahan ng Bessemer Venture Partners at ang beta release ng Andi, ang AI integration agent nito. Lumahok sa round ang dati nang mga investor na Matrix at Flex Capital, kasama ang mga bagong investor na Yelp, Tenacity Capital, CTO Fund at Mana Ventures. Inaasahang sasali rin sa board ng kompanya si Lauri Moore, partner sa Bessemer.

Sa tala ng Axios, nakalista rin ang $15M na funding mula sa Bessemer para sa Ampersand, na inilalarawan nito bilang integration infrastructure platform. Ang problemang tinutugunan ng kompanya ay pamilyar sa gumagawa ng enterprise AI software: kayang magpasya ng agent kung anong record ang kailangan nito, ngunit dapat pa ring maikonekta nang tama ang aksiyong iyon sa sariling CRM o ERP ng bawat customer. Nagiging hadlang ang mga sistemang iyon kapag magkaiba ang kanilang mga object, field, pahintulot at workflow kahit pareho ang pangalan ng ginagamit na software.

Bakit hindi sapat ang koneksiyon sa CRM

Ang isang gumaganang API connection ay simula pa lamang ng integration. Maaaring pareho ang CRM platform ng dalawang negosyo ngunit magkaiba ang paraan nila ng pagtatala ng sales opportunity, pag-uugnay ng customer record at pagbibigay ng karapatang magbago ng field. Kailangang malaman ng application kung ano ang ibig sabihin ng lokal na data model bago nito maipabasa o maipabago sa agent ang tamang record.

Sa panayam ng Bessemer, ganito inilarawan ng mga tagapagtatag na sina Ayan Barua at Lauren Long ang trabahong nais nilang bawasan: “It replaces one integration per customer.” Sa dati nilang inilalarawang proseso, muling inaangkop ng vendor ang bahagi ng integration para sa bawat bagong account. Nagmamapa ang mga engineer ng mga field sa onboarding at bumabalik sa koneksiyon kapag nagbago ang schema o nag-expire ang credentials.

Mas mahalaga ang lokal na kahulugan ng data kapag agent ang gagawa ng aksiyon. Ang field na nagsasabing kwalipikado ang isang deal, halimbawa, ay maaaring custom field sa isang customer at bahagi ng ibang workflow sa kasunod. Kung maling field ang nabasa, maaaring mali ang konklusyon ng agent; kung maling record ang nasulatan, maaari namang kumalat ang pagbabago sa mga kasunod na proseso ng negosyo. Iyan ang dahilan kung bakit nagiging bottleneck ang bawat customer configuration sa halip na ang unang pagkuha lamang ng access sa API.

Paano iniuugnay ng Ampersand ang read at write actions

Sa inilalarawang arkitektura ng Ampersand, idinedeklara ng developer ang integration sa version-controlled code gamit ang read, write, subscribe, search at proxy operations. Sa runtime, inaangkop ang integration sa schema ng customer, habang ang administrator ng customer ang nagmamapa ng mga field sa onboarding flow ng vendor. Nananatili sa developer ang lohika ng application, at sa customer ang pagpili kung paano tutugma ang mga field nito sa lohikang iyon.

Layunin ng ganitong disenyo na mapanatili ang sariling istruktura ng bawat CRM o ERP. Mahalaga iyon sa bi-directional na aksiyon: kukuha ang application ng konteksto mula sa system of record at magsusulat pabalik ng pagbabagong pinapayagan sa kapaligirang iyon. Maaaring sapat ang isang pangkalahatang data field para sa payak na demo, ngunit ang custom objects at fields ang kadalasang naglalaman ng impormasyong kailangan sa aktuwal na operasyon ng customer.

Ang read at write ay magkaibang antas ng pananagutan. Sa read action, maaaring magbunga ng maling sagot ang maling mapping. Sa write action, maaaring mabago ang mismong talang pagbabatayan ng ibang empleyado o workflow. Ang kakayahang tumawag ng write operation ay hindi kusang nangangahulugang may pahintulot ang agent sa bawat object o field; nakasalalay pa rin ang saklaw nito sa configuration at access na ibinigay sa koneksiyon.

Andi at ang tuloy-tuloy na maintenance

Ang Andi ay inilabas sa beta upang tumulong sa implementation work na kailangan para gumana ang produkto ng developer sa kapaligiran ng bawat customer. Mahalaga ang saklaw ng gawaing iyon dahil maaaring manatiling konektado ang isang application habang nagbabago na ang kahulugan ng mga field o ang pahintulot sa likod nito. Ang pagbabago sa schema, pag-expire ng credentials at koneksiyong tahimik na pumapalya ay maaaring huminto sa dating gumaganang aksiyon ng agent.

Inilalarawan ng Ampersand ang schema-drift auditing, awtomatikong pamamahala ng credentials at real-time alerts bilang bahagi ng pagharap nito sa maintenance. Magkakaugnay ang mga ito ngunit magkakaiba ang silbi: kailangang matukoy ang pagbabago sa istruktura, maibalik ang wastong access at makita kung pumalya ang operasyon. Para sa vendor na may maraming customer, ang halaga ng integration layer ay nasa pagpapanatiling tugma ng bawat koneksiyon habang nagbabago ang kani-kanilang sistema, hindi lamang sa pagpapagana nito sa unang araw.

Sino ang may hawak sa write access

Kapag papayagan nang magsulat ang agent sa CRM o ERP, kailangang malinaw kung aling pagbabago ang maaari nitong gawin at sino ang mananagot kapag mali ang resulta. Isang maling update sa deal status, customer field o ERP record ang maaaring maging batayan ng susunod na awtomatikong aksiyon. Magkahiwalay ding usapin ang pagtuklas ng schema drift at ang pagkakaroon ng kumpletong tala ng bawat transaksiyong isinulat ng agent.

Para sa technology buyer, may mga tanong na direktang sumusunod sa disenyo ng ganitong integration:

  • Aling objects, fields at operasyon ang maaaring baguhin, at sino sa customer ang nag-aapruba ng mapping at pahintulot?
  • Paano makikita kung tinanggihan ang isang write, bahagya itong nagtagumpay, o naulit matapos ang retry?
  • Anong tala ang mag-uugnay sa utos ng agent, ginamit na pahintulot, dating halaga at naging pagbabago sa record?
  • Sino ang magwawasto ng maling update, at paano pipigilan ang mga kasunod na aksiyon habang iniimbestigahan ito?

Mga tanong ito tungkol sa pagpapatakbo, hindi mga kontrol na napatunayang kasama na sa beta ng Andi. Sa bawat deployment, kailangang magkasundo ang software vendor at customer kung saan nagsisimula at nagtatapos ang kanilang responsibilidad sa pahintulot, audit trail at pagwawasto. Doon masusukat kung ang ipinangakong read at write access ay makagagana sa tunay na configuration ng negosyo nang nananatiling nasusubaybayan ang bawat pagbabagong ginagawa ng agent.

Basahin din:

I-share:

Mag-subscribe sa aming newsletter

Matanggap ang pinakabagong balita tungkol sa Web3, AI at crypto nang diretso sa iyong inbox.

0