మాట్లాడకుండానే నిర్ణయం తీసుకోవడం నేర్చుకుంటున్న AI

గత కొన్ని సంవత్సరాలుగా చాలా AI systems ఒకే ప్రాథమిక ఆలోచన చుట్టూ నిర్మితమయ్యాయి:

model కు ఏదైనా input ఇచ్చి, సమాధానాన్ని generate చేయమని అడగడం.

ఒక వ్యక్తికి టెక్స్ట్, code, వివరణ లేదా సంభాషణ అవసరమైనప్పుడు ఇది బాగా పనిచేస్తుంది.

కానీ software కు తరచుగా దీనికంటే చాలా సరళమైనది కావాలి.

ఈ request ను ఏ team అందుకోవాలి?

agent ఏ tool ను call చేయాలి?

ఈ action కొనసాగాలా, ఆగాలా?

ఈ output ఆమోదయోగ్యమేనా?

తదుపరి step ను ఏ model నిర్వహించాలి?

ఇవి రాయడానికి సంబంధించిన సమస్యలు కావు.

ఇవి నిర్ణయ సమస్యలు.

ఇలాంటి పని కోసమే ప్రత్యేకంగా రూపొందిస్తున్న AI systems కొత్త సమూహం ఇప్పుడు వస్తోంది.

TypeSafe కు చెందిన Jev, OpenAI కు చెందిన Decisions API, AWS కు చెందిన open-source Strands Decider అన్నీ ఒకే దిశను సూచిస్తున్నాయి:

కొన్నిసార్లు software కు మాట్లాడే AI అవసరం ఉండదు. ఎంచుకునే AI కావాలి.

ప్రతి నిర్ణయానికీ పూర్తి language model ఎందుకు వాడాలి?

ఒక AI support agent ను ఊహించండి.

దానికి ఈ request వస్తుంది:

“నా payout మూడు రోజులుగా విఫలమవుతోంది.”

ఈ request ఏ విభాగానికి చెందుతుందో system నిర్ణయించాల్సి రావచ్చు:

• billing
• sales
• retail support

large language model ఆ నిర్ణయం తీసుకోగలదు.

మీరు దానికి ఇలా prompt ఇవ్వవచ్చు:

ఈ మూడు విలువల్లో ఒక్కదాన్ని మాత్రమే return చేయి.

structured JSON ఇవ్వమని కూడా అడగవచ్చు.

అది పనిచేస్తుంది.

కానీ మౌలికంగా ఆ model ఇప్పటికీ ఒక text generator.

software కు అనుమతించిన ప్రతి output ముందే తెలిసినప్పటికీ, అది request ను process చేసి, tokens ను అంచనా వేసి, సమాధానాన్ని generate చేస్తుంది.

application కు వచన రూపం అవసరం లేదు.

దానికి కావాల్సింది:

billing

దీనితో పాటు, వీలైతే:

నీకు ఎంత confidence ఉంది?

decision-oriented systems పూరించడానికి ప్రయత్నిస్తున్న లోటు ఇదే.

ఈ చిత్రం కోసం టెక్స్ట్ వివరణ

పక్కపక్కనే రెండు flows. Generative AI: input ఒక model కు వెళ్తుంది, అది open-ended generated output ఇస్తుంది, ఉదాహరణకు payment ఎందుకు విఫలమైందో వివరణ. Output box ను dashed outline తో గీశారు, ఎందుకంటే దాని ఆకారం ముందే నిర్ణయించబడదు. Decision AI: state, అనుమతించిన ఎంపికలు ఒక decision system కు వెళ్తాయి, అది ఎంచుకున్న option ను, మద్దతు ఉన్నచోట confidence లేదా probability ను ఇస్తుంది, ఉదాహరణకు billing, sales లేదా support. ప్రతి step కు text label ఉంది, కాబట్టి అర్థం రంగుపై ఆధారపడదు.

Jev ఈ వ్యత్యాసాన్ని స్పష్టం చేసింది

TypeSafe 2026 సెప్టెంబర్‌లో Jev ను తన మొదటి System One Model గా పరిచయం చేసింది.

model గురించి మేము ఇంతకుముందు TechiesJournal వ్యాసంలో వివరించాం, కాబట్టి ఈ వ్యాసం విస్తృత వర్గంపై దృష్టి పెడుతుంది.

కంపెనీ ఈ interface ను సరళంగా ఇలా వివరిస్తోంది:

unstructured state లోపలికి → typed probabilistic decisions బయటికి

టెక్స్ట్ generate చేయడానికి బదులుగా, Jev ఒక state ను, developer నిర్వచించిన ప్రశ్నలు లేదా options సమితిని అందుకుంటుంది.

అది structured ఎంపికలను, వాటి probabilities ను తిరిగి ఇస్తుంది.

TypeSafe చెబుతోంది: Jev కొత్త architecture ను, parallel sampler ను, Reinforcement Learning for Calibrated Decisions లేదా RLCD అనే training విధానాన్ని ఉపయోగిస్తుంది. సరైన option ను ఎంచుకోవడమే కాకుండా, చెప్పిన probabilities ను అనిశ్చితికి ఉపయోగకరమైన అంచనాలుగా మార్చడం లక్ష్యం.

అంటే ఒక application ఇలాంటి నియమాలను నిర్వచించవచ్చు:

confidence 0.95 కంటే ఎక్కువ → ఆటోమేటిక్‌గా కొనసాగించు

confidence 0.70 నుండి 0.95 మధ్య → మరో check చేయి

confidence 0.70 కంటే తక్కువ → వ్యక్తిని అడుగు

model ఇచ్చిన సమాధానం నమ్మకంగా వినిపిస్తోందన్న కారణంతోనే దాన్ని నమ్మదగినదిగా భావించడం కంటే ఇది చాలా భిన్నం.

కానీ ఒక పరిమితి స్పష్టంగా ఉండాలి:

calibrated అంటే ఎల్లప్పుడూ సరైనది అని అర్థం కాదు.

model ఇప్పటికీ తప్పు సమాధానాన్ని ఎంచుకోవచ్చు.

Calibration అంటే, ఒకే రకమైన అనేక నిర్ణయాల్లో, దాని probabilities ఆ నిర్ణయాలు ఎంత తరచుగా సరైనవో దానికి సహేతుకంగా సరిపోలాలి.

స్వతంత్ర పరిశోధన Jev launch అయిన కొద్దికాలానికే ప్రచురితమైంది. అది పెద్ద సంఖ్యలోని classification, reasoning datasets లో ఉపయోగకరమైన probability calibration తో సహా ప్రోత్సాహకరమైన ఫలితాలను కనుగొంది. అదే సమయంలో noisy labels, fine-grained classification, కొన్ని rubric-based judgments వంటి రంగాల్లో బలహీనమైన పనితీరును కూడా కనుగొంది.

కాబట్టి Jev కు సంబంధించిన తొలి ఆధారాలు ఆశాజనకంగా ఉన్నాయి, కానీ decision models వల్ల evaluation అవసరం తొలగిపోదు.

OpenAI అదే సమస్యకు మరో దిశ నుండి చేరింది

DevDay 2026 లో OpenAI Decisions API ను ప్రకటించింది.

ఈ interface ఇలాంటి పనుల కోసం ఉద్దేశించింది:

• classification
• request routing
• agent తదుపరి action ను ఎంచుకోవడం
• పునరావృతమయ్యే business నిర్ణయాలు

Jev తో ఉన్న సారూప్యత స్పష్టంగా కనిపిస్తుంది.

open-ended సమాధానం అడగడానికి బదులుగా developer ఒక decision space ను నిర్వచిస్తారు.

కానీ ఇక్కడ ఒక ముఖ్యమైన సాంకేతిక తేడా ఉంది.

Decisions API కు GPT-6 Luna శక్తినిస్తుందని OpenAI చెబుతోంది.

దీన్ని Jev తరహా ప్రత్యేక model architecture గా OpenAI బహిరంగంగా వివరించలేదు, calibrated decisions కోసం ప్రత్యేకించిన Jev లాంటి training పద్ధతిని కూడా వెల్లడించలేదు.

కాబట్టి ప్రస్తుతం Decisions API ని ఇలా వర్ణించడం సురక్షితం:

OpenAI యొక్క విస్తృత model platform పై నిర్మితమైన decision-oriented service

ఇలా కాకుండా:

Jev కు సమానమైన ప్రత్యేక decision model.

ఈ తేడా ముఖ్యం కావచ్చు.

Luna ని ఉపయోగించడం వల్ల OpenAI కు విస్తృత language, multimodal సామర్థ్యాలు అందుబాటులో ఉండే అవకాశం ఉంది.

Jev లాంటి మరింత ప్రత్యేకమైన system కు efficiency, calibration లేదా ఊహించదగిన machine-oriented outputs లో ప్రయోజనాలు ఉండవచ్చు.

ఆ trade-off చివరకు ఎటు మొగ్గుతుందో నిర్ణయించడానికి తగినంత బహిరంగ ఆధారాలు మా వద్ద ఇంకా లేవు.

Decisions API ఇప్పటికీ limited preview లోనే ఉంది, కాబట్టి వివరణాత్మక స్వతంత్ర పరీక్షలు ఇంకా తక్కువగా ఉన్నాయి.

AWS specialization విధానాన్ని మరింత ముందుకు తీసుకెళ్లింది

ఆ తర్వాత AWS Strands బృందం agentic workflows కోసం ఉద్దేశించిన open-source decision model అయిన Strands Decider ను విడుదల చేసింది.

దీని architecture అసాధారణంగా పారదర్శకంగా ఉంది.

ఈ project ముందే train చేసిన Qwen3.5-2B language-model body తో మొదలవుతుంది, language-generation head ను తొలగించి, దాని స్థానంలో చిన్న decision head ను ఉంచుతుంది.

అంటే ఈ model ఇకపై ఇష్టానుసారం టెక్స్ట్‌ను generate చేయదు.

ఇది ముందే నిర్వచించిన ఎంపికలకు నేరుగా score ఇస్తుంది.

విడుదలైన మొదటి model కు సుమారు 1.9 billion parameters ఉన్నాయి. AWS తెలిపిన ప్రకారం, దాని reference setup లో RTX 3090 పై median response time సుమారు 115 milliseconds. ఇది Apple Silicon, CPU ఆధారిత systems పై locally కూడా నడవగలదు.

దీని ఉద్దేశిత ఉపయోగాల్లో ఇవి ఉన్నాయి:

• model routing
• tool selection
• tool-argument checking
• triage
• guardrails
• evaluations
• hybrid agent workflows

చివరిది ముఖ్యంగా ఆసక్తికరం.

నిజంగా కఠినమైన reasoning కోసం పెద్ద language model ను ఉపయోగించి, సాధారణ ఎంపికలను చిన్న decision model కు వదిలేయాలని AWS సూచిస్తోంది.

ఇది ఒక ముఖ్యమైన architecture pattern గా మారవచ్చు.

భవిష్యత్ agent ఒకటి కంటే ఎక్కువ రకాల intelligence ను ఉపయోగించవచ్చు

ఈ రోజు చాలా agent systems దాదాపు ఇలా ఉంటాయి:

LLM → tool ఎంపిక → LLM → result పరిశీలన → LLM → తదుపరి step నిర్ణయం → LLM → output మూల్యాంకనం

ప్రతి intelligent step ఒకే general-purpose model ద్వారా వెళ్తుంది.

Decision models మరో design ను సూచిస్తున్నాయి:

decision model → సాధారణ routing

decision model → tool ఎంపిక

large model → కఠినమైన reasoning

decision model → output తనిఖీ

human → అధిక ప్రమాదం లేదా అనిశ్చితి ఉన్న కేసు

ఈ చిత్రం కోసం టెక్స్ట్ వివరణ

పైన: సంప్రదాయ పద్ధతి, ఇందులో ఒకే general-purpose large language model ప్రతి step ను చేస్తుంది: tool ఎంపిక, result పరిశీలన, తదుపరి step నిర్ణయం, మూల్యాంకనం. కింద: ఐదు పాత్రలతో సాధ్యమయ్యే layered పద్ధతి. ఒక decision model సాధారణ routing ను నిర్వహిస్తుంది. ఒక decision model tool ఎంపికను నిర్వహిస్తుంది. ఒక large language లేదా reasoning model కఠినమైన reasoning ను నిర్వహిస్తుంది. ఒక decision model సాధారణ evaluation ను నిర్వహిస్తుంది. అనిశ్చితమైన లేదా తీవ్ర పరిణామాలు ఉన్న నిర్ణయాలను ఒక human నిర్వహిస్తాడు. ఈ చిత్రం ఒక architectural అవకాశంగా మాత్రమే సూచించబడింది, స్థిరపడిన సార్వత్రిక best practice కాదు. ప్రతి పాత్రకు text label ఉంది, కాబట్టి అర్థం రంగుపై ఆధారపడదు.

ఈ విభజన వీటిని తగ్గించవచ్చు:

• latency
• inference cost
• అనవసరమైన generation
• variability

అనుమతించిన outputs model నడవడానికి ముందే నిర్వచించబడతాయి కాబట్టి, కొన్ని నిర్ణయాలను audit చేయడం కూడా సులభం కావచ్చు.

కానీ ఇది మరో బాధ్యతను తెస్తుంది:

ఏ నిర్ణయాలను పరిమితం చేయడం సురక్షితమో developers నిర్ణయించాలి.

కొన్ని నిర్ణయాలను ఒక menu లోకి కుదించకూడదు

సాధ్యమయ్యే ఫలితాలు తెలిసినప్పుడు decision models ఉత్తమంగా పనిచేస్తాయి.

ఉదాహరణకు:

ఏ support queue?

ఏ tool?

ఈ transaction అనుమానాస్పదమా?

ఈ సమాధానం policy కి అనుగుణంగా ఉందా?

కానీ కొన్ని పనులు నిజంగా open-ended.

ఒక model ఇవి చేయాల్సి రావచ్చు:

• దర్యాప్తు చేయడం
• వివరించడం
• రాయడం
• ఆధారాలను క్రోడీకరించడం
• ప్రణాళికను ప్రతిపాదించడం
• developer ఊహించని ఒక option ను కనుగొనడం

సరైన సమాధానం ముందే నిర్వచించిన choice set లో లేకపోతే, decision model దాన్ని సృష్టించలేదు.

ఇది బలం కూడా, పరిమితి కూడా.

output అనుమతించిన నిర్మాణం దాటి బయటకు వెళ్లలేదు.

కానీ ఆ నిర్మాణమే సరిపోయేలా ఉందో లేదో చూసుకునే బాధ్యత system designer దే.

“Cannot hallucinate” అనే మాటను జాగ్రత్తగా చెప్పాలి

Jev ఇష్టానుసారం strings ను generate చేయదు కాబట్టి అది hallucinate చేయలేదని TypeSafe చెబుతోంది.

ఆ ప్రకటన వెనుక ఒక ఉపయోగకరమైన ఆలోచన ఉంది, కానీ దాన్ని సులభంగా తప్పుగా అర్థం చేసుకోవచ్చు.

అనుమతించిన outputs ఇవి అనుకుందాం:

• approve
• reject

decision model అకస్మాత్తుగా ఇలా return చేయలేదు:

“దీన్ని మరో విభాగానికి పంపండి.”

ఇది నిజం.

కానీ అది ఇప్పటికీ తప్పుగా ఇలా return చేయవచ్చు:

approve

సరైన నిర్ణయం ఇది అయినప్పుడు:

reject.

కాబట్టి మరింత కచ్చితమైన వర్ణన ఇది:

ఒక constrained decision model schema బయటి సమాధానాన్ని generate చేయలేదు, కానీ schema లోపలే తప్పు నిర్ణయం తీసుకోవచ్చు.

అందుకే calibration, evaluation అంత ముఖ్యం.

Developers ఎందుకు శ్రద్ధ పెడుతున్నారు

ప్రతి step కు LLM పూర్తి ఖర్చు లేదా సామర్థ్యం customers కు అవసరం లేని agent workflows నుండి ఈ ప్రేరణ వచ్చిందని AWS distinguished engineer Marc Brooker TechCrunch కు చెప్పారు.

ఇలాంటి ప్రశ్నలకు decision models ముఖ్యంగా ఉపయోగకరమని ఆయన వర్ణించారు:

workflow తదుపరి ఏమి చేయాలి?

అలాగే constrained answers, confidence scores, తక్కువ latency, తక్కువ ఖర్చు అయ్యే అవకాశం అనే కలయికను ఆయన ప్రముఖంగా పేర్కొన్నారు.

Jev చుట్టూ స్వతంత్ర developers చూపుతున్న ఆసక్తి కూడా ఇలాంటి తీరునే అనుసరించింది: routing, classification, robotics, agent control తరచుగా వచ్చే use cases లో ఉన్నాయి.

నిజమైన డిమాండ్ మరో chatbot కోసం కాదని ఇది సూచిస్తోంది.

అది సాధారణ software control flow లోపల పొందుపరిచిన చిన్న intelligence భాగాల కోసం.

ఇవి కొత్త పేరుతో వస్తున్న classifiers మాత్రమేనా?

ఇది సహేతుకమైన ప్రశ్న.

సంప్రదాయ machine-learning classifiers ఏళ్లుగా structured decisions ను నిర్వహిస్తున్నాయి.

fraud classifier, sentiment model లేదా routing model ఇప్పటికే ఒక probability ను ఇవ్వగలవు.

ఈ కొత్త systems అందించడానికి ప్రయత్నిస్తున్న తేడా generality, అంటే విస్తృతంగా వర్తించే సామర్థ్యం.

సంప్రదాయ classifier కు సాధారణంగా ఇవి అవసరం:

• నిర్వచించిన పని
• labeled data
• training
• deployment
• maintenance

ప్రతి పనికీ విడిగా classifier ను train చేయకుండా, runtime లో కొత్త natural-language నిర్ణయాన్ని స్వీకరించడమే decision model లక్ష్యం.

ఆ కోణంలో, ఇది వీటి మధ్య ఎక్కడో ఉంటుంది:

సంప్రదాయ classifier

మరియు

general-purpose LLM.

Strands Decider ను AWS స్పష్టంగా ఇలా వర్ణిస్తోంది: సంప్రదాయ classifier కు చాలా task-specific training అవసరమయ్యే, కానీ పూర్తి LLM అనవసరమైన సమస్యలకు ఇది ఉపయోగకరం.

ఈ వర్గానికి అత్యంత ఉపయోగకరమైన నిర్వచనం ఇదే కావచ్చు.

అతి పెద్ద అవకాశం agents లోపలే ఉండవచ్చు

ఈ పరిణామం ఎక్కువసేపు నడిచే AI agents వైపు మళ్లుతున్న మార్పుతో నేరుగా ముడిపడి ఉంది.

ఒక పని పూర్తి చేసే క్రమంలో ఒక agent వందలాది చిన్న నిర్ణయాలు తీసుకోవచ్చు.

ప్రతి ఎంపికకూ frontier model call అవసరమైతే, ఖర్చులు, ఆలస్యాలు పెరుగుతూ పోతాయి.

ఈ ప్రశ్నలను చూడండి:

• ఏ document ను retrieve చేయాలి?
• search result సంబంధితమేనా?
• ఏ API ని call చేయాలి?
• ఈ arguments సరైనవేనా?
• tool ఉపయోగపడే result ఇచ్చిందా?
• మళ్లీ ప్రయత్నించాలా?
• escalate చేయాలా?
• చివరి సమాధానానికి తగినంత ఆధారం ఉందా?

వాటన్నింటికీ frontier స్థాయి reasoning అవసరం లేదు.

ప్రత్యేకమైన decision models సాధారణ ఎంపికలను నమ్మదగిన రీతిలో నిర్వహించగలిగితే, లోతైన reasoning నిజంగా విలువ చేకూర్చే భాగాల కోసం పెద్ద models ను ఉంచవచ్చు.

దీనివల్ల agent systems తప్పనిసరిగా సామర్థ్యం తగ్గకుండానే చౌకగా, వేగంగా మారవచ్చు.

నా దృక్కోణం: intelligence కు ఒకే interface అవసరం లేదు

ఏళ్లుగా generative AI ఒక సరళమైన ఊహను ప్రోత్సహించింది:

software కు intelligence కావాలంటే, LLM ని call చేయండి.

Jev, OpenAI Decisions API, Strands Decider ఆ ఊహను సవాలు చేస్తున్నాయి.

ఇవి మరింత layered భవిష్యత్తును సూచిస్తున్నాయి.

software generate చేయడానికి, reason చేయడానికి లేదా అన్వేషించడానికి అవసరమైనప్పుడు language model ను ఉపయోగించండి.

software కు సాధ్యమయ్యే ఫలితాలు ముందే తెలిసి, వాటి మధ్య ఎంచుకోవడంలో సహాయం కావాల్సినప్పుడు decision system ను ఉపయోగించండి.

సమాధానానికి అసలు AI అవసరం లేనప్పుడు deterministic code ను ఉపయోగించండి.

అనిశ్చితి లేదా పరిణామాల కారణంగా automation తగనప్పుడు నిర్ణయాన్ని ఒక వ్యక్తికి అప్పగించండి.

కాబట్టి ముఖ్యమైన ప్రశ్న ఇది కాదు:

Decision models LLMs ను భర్తీ చేస్తాయా?

బహుశా కాదు.

అసలు ప్రశ్న ఇది:

ఈ రోజు LLM workload లో ఎంత భాగానికి అసలు language generation ఎప్పుడూ అవసరం లేదు?

సమాధానం గణనీయంగా ఉంటే, decision-oriented AI భవిష్యత్ software, agent systems లోపల ఒక ముఖ్యమైన layer గా మారవచ్చు.

యంత్రాలకు intelligence అవసరం లేకుండా పోయినందువల్ల కాదు.

intelligence ఎల్లప్పుడూ మాట్లాడాల్సిన అవసరం లేదు కాబట్టి.

మూలాలు

మూలాలు సమీక్షించిన తేదీ: 2 అక్టోబర్ 2026.

1. TypeSafe AI — Introducing System One Models & Jev. Jev architecture, decision interface, RLCD training claims ను వివరించే ప్రాథమిక launch సమాచారం.
2. Strands Labs — Strands Decider. Open-source model architecture, evaluation, local deployment సమాచారం, agent-workflow use cases.
3. Evaluating and Benchmarking the System One Model Jev. 37 datasets లో స్వతంత్ర evaluation, accuracy, calibration ఫలితాలతో సహా.
4. Calibrated Decisions at Scale. పెద్ద స్థాయి structured coding, human-review gating కోసం Jev ను ఉపయోగించిన applied research.
5. OpenAI — DevDay 2026 Announcements and Developer Resources. Decisions API ప్రకటన, దాని limited-preview స్థితి గురించిన అధికారిక సారాంశం.
6. TechCrunch — Amazon releases its own Jev clone as decision models flood the web. agentic workflows లో decision models పై పరిశ్రమ వ్యాఖ్యానం, AWS engineering దృక్పథం.