Explore enterprise products and AI capabilities built for industry.
Let’s talk about your businessProducts, integrations and partnershipsBring AI into the enterprise.
Automated data-warehouse builder
Automated high-quality datasets
AI appliance for business decisions
Opens in a new tabDedicated offline AI bidding appliance
Connect AI to products and operations.
Explore the interfaces and integration paths for our AI capabilities.
Models, foundational frameworks and the engineering behind AI systems.
Explore collaboration across products, technology and delivery.
Frameworks, tools and examples for developers to understand and reuse.
Updates, technical thinking and industry observations from IDENIFE.
Our focus on education, talent and sharing knowledge.
RESEARCH / 03Agents & execution frameworks
Methods & systemsAn agent’s work extends beyond the next sentence.
It must understand a goal, change a state and show evidence that the task is done.
Read the goal and the state
Choose a step and its test
Invoke a concrete capability
Bring the result back to evidence
01From answers to tasks
A language model produces candidate explanations and actions. Task completion happens outside it: a correct file, a satisfied rule, an actual state change. These require different judgments.
This is a statement. It does not establish source validity, complete coverage of constraints or acceptance by a target system.
02The reasoning–action loop
ReAct interleaves reasoning and actions so observations can inform the plan. Task systems also need explicit acceptance checks: receiving a tool result does not establish that the goal is met.
ReActHow an outdated brief changes the next step.
Sample brief v2 · §3 Non-invasive mounting · version conflict
A failure should reduce uncertainty. Record which assumption failed, what evidence changed and which step needs repair before attempting the task again.
Reflexion03Choosing a topology
Adding agents changes parallelism, context allocation and coordination cost. Choose a structure around task dependencies and verification. These are three designs to compare, not a ranking of performance.
Tasks with tight dependencies, concentrated context and a manageable tool set. Establish this baseline before testing a split.
Suggested comparison: hold the model, tools, tasks and budget constant. Test a single-agent baseline, then add parallel work or separate review to see whether the benefit offsets handoff costs.
04Tool and context boundaries
Toolformer studies learning to select APIs and use their results. Engineering must also define inputs, outputs, side effects and failure semantics. Selecting a tool is the beginning of an action.
ToolformerAssemble context by role, task and data permissions. A subagent receives a bounded objective and evidence, then returns an artifact with sources, reducing repeated copies of the whole conversation.
Documents, web pages and tool results are external data. Instructions inside them do not expand the task’s authorization. Even after schema validation, services must check access and business conditions.
05Memory and provenance
Context is finite while tasks may continue. Compaction should preserve goals, constraints, unresolved questions and retrievable references. Shortening a conversation does not make its claims more reliable.
Preserve identity, version and access scope.
Bring the source location into this step.
Separate known constraints, candidates and open checks.
Reflexion explores verbal feedback and episodic memory for later trials. The research question here is which feedback to retain and how to avoid preserving a mistaken summary as durable knowledge. Reflexion
Task checkpoints capture current state; cross-task memory retains information for a defined purpose. Specify permissions, expiry and deletion separately. LangGraph’s checkpoint/store distinction offers an engineering reference. LangGraph · Persistence
06Bounded execution
An execution framework needs conditions for continuing and explicit states for failure, waiting and stopping. Repetition without progress is not a measure of autonomy.
Set limits for tool calls, model usage, elapsed time and retries before starting. At the limit, save partial artifacts and unfinished work.
Retry recoverable failures with new information or explicit backoff. Reconcile uncertain write receipts first; repeating a call does not make it idempotent.
Bind approval to a concrete action, resource scope and change version. Existing authorization persists within its valid scope; changed content requires reassessment.
Keep the state version, input references and tool receipts. Reconcile external state before resuming instead of treating an old snapshot as current fact.
When new evidence is unavailable, a hard constraint cannot be met or an action exceeds authorization, stop with a useful handoff.
07Evaluation design
| Dimension | What to establish | Suggested reporting |
|---|---|---|
| Task completion | Judge completion against predefined artifacts and final environment state. | Completion rate = accepted tasks / all evaluated tasks. Report aborts and failure causes separately. |
| Trace correctness | Check whether actions, arguments, ordering and cited evidence support the result. | Allow multiple valid paths. Check critical invariants and events instead of enforcing one exact sequence. |
| Constraint compliance | Test permissions, data scope, write conditions and prohibited actions. | Declare hard constraints in advance. A violation disqualifies success; report violation types separately. |
| Execution cost | Include model usage, tools, compute and failed attempts. | Report cost per attempt and total cost / successful tasks, with a cost breakdown and pricing date. |
| Latency & consistency | Measure from task acceptance to result readiness, across repeated runs. | Report median and tail latency, timeouts, retries and consistency across trials. Identify human waiting time separately. |
Compare cost and speed after hard constraints are satisfied.
Fix the task set and difficulty strata. Record model and tool versions, prompts, budgets, randomness and evaluators; keep evaluation tasks separate from tuning. Repeat each task, retain failures and uncertainty estimates, and compare retrieval, memory, review and parallelism separately.
Read more: evaluating tool agentsThese are evaluation proposals. This page reports no measured IDENIFE scores, benchmark rankings or deployment outcomes.
08From methods to systems
Within IDENIFE’s technology system, ID Axis connects model reasoning, task orchestration and tool calls. This page examines agent methods; execution foundations, application integration and protocol access each have their own treatment.
Original papers & specifications
External research informs the discussion; it does not imply a partnership with the authors or institutions.
Interleaves reasoning and action, using environmental feedback to update subsequent steps.
Uses self-supervised training to learn API selection, arguments and use of returned results.
Uses verbal feedback and episodic memory to inform later attempts without updating model weights.
Uses real repositories and issues to evaluate outcomes through code changes and execution.
Combines user interaction, domain rules and tools to examine final states and reliability across trials.
Distinguishes thread checkpoints from cross-thread stores, informing continuity and memory boundaries.
Defines tool inputs and optional output schemas; declarations do not replace application authorization.
This page presents methods and evaluation designs for agent systems. Interactions are constructed examples; implementation and availability are described in the relevant product and developer documentation.