The 4 Pillars of an AI Agent<\/h2>\n\n\n\n Every agentic system\u2014regardless of framework, model, or use case\u2014is built from four components that work in concert. Understanding each component independently is the prerequisite for understanding how they combine into a working agent.<\/p>\n\n\n\n
Pillar 1: Perception and Context \u2014 How Agents Know What They Know<\/h3>\n\n\n\n An agent that cannot access relevant information cannot reason about relevant problems. The perception layer is how an agent ingests the data it needs to act intelligently.<\/p>\n\n\n\n
For most production agents, this means Retrieval-Augmented Generation (RAG). The agent does not attempt to hold all relevant knowledge in its context window\u2014a physical impossibility given context window limits and a cost impossibility given token pricing. Instead, at each reasoning step, it retrieves the specific information relevant to that step from a vector database, a document store, a structured database, or a live API.<\/p>\n\n\n\n
This distinction matters architecturally. A naive agent implementation might try to give the agent every potentially relevant document upfront. A well-designed agent retrieves precisely what it needs, when it needs it, in response to the specific sub-task it is currently pursuing. The second approach scales; the first does not.<\/p>\n\n\n\n
What the perception layer can ingest:<\/strong><\/p>\n\n\n\n\nUnstructured text (documents, support articles, emails) via RAG over a vector store<\/li>\n\n\n\n Structured data (database records, CRM entries, transaction histories) via query tools<\/li>\n\n\n\n Real-time data (current prices, live status updates, web search results) via API tools<\/li>\n\n\n\n Previous agent outputs and conversation history from memory (covered in Pillar 4)<\/li>\n<\/ul>\n\n\n\nThe quality of an agent’s perception directly determines the quality of its reasoning. An agent asked to summarise a customer’s account history that can only retrieve their last five transactions will produce a less accurate summary than one that can retrieve the complete history. Designing the retrieval layer carefully is not secondary infrastructure work\u2014it is core product engineering.<\/p>\n\n\n\n
Pillar 2: Reasoning \u2014 The LLM as Planning Engine<\/h3>\n\n\n\n The LLM is the agent’s brain. It takes the context assembled by the perception layer, the agent’s goal, its available tools, and its conversation history, and decides what to do next.<\/p>\n\n\n\n
This is a fundamentally different use of an LLM than generative tasks. In a generative task, the model produces a final output. In an agentic task, the model produces a plan<\/em>\u2014specifically, a decision about which tool to call, with what arguments, in pursuit of what intermediate goal. The output is not the answer to the user’s question. It is the next action.<\/p>\n\n\n\nThe quality of an LLM’s reasoning directly determines the quality of the agent’s behaviour. Models that are strong at multi-step reasoning, instruction following, and structured output produce more reliable agents than models that are weaker on these dimensions, even if those weaker models are competitive on other benchmarks.<\/p>\n\n\n\n
Model selection for agentic workloads in 2026:<\/strong><\/p>\n\n\n\nClaude 3.5 Sonnet (Anthropic)<\/strong> has become a practical standard for reasoning-heavy agentic tasks. Its ability to follow complex, multi-conditional system prompts reliably, its strong performance on tool use, and its relatively low rate of premature task termination make it a strong default for agents that need to execute multi-step plans correctly. For agentic tasks where the agent needs to reason through ambiguity, decompose a complex goal into sub-tasks, or follow a detailed operational protocol, Claude 3.5 Sonnet’s reasoning quality is consistently competitive.<\/p>\n\n\n\nGPT-4o (OpenAI)<\/strong> is the primary alternative, with strong tool use performance and the addition of multimodal perception\u2014making it relevant for agents that need to interpret visual inputs (screenshots, charts, scanned documents) as part of their reasoning.<\/p>\n\n\n\nLlama 3 (Meta, self-hosted)<\/strong> is the relevant choice for agents operating in privacy-constrained environments where data cannot leave your infrastructure. Agentic workloads over sensitive financial, medical, or legal data often cannot use third-party API providers without compliance risk. Self-hosted Llama 3 trades some reasoning quality for data sovereignty. For agent tasks that are not reasoning-heavy (structured data extraction, classification, short-form generation), the quality gap is manageable.<\/p>\n\n\n\nThe practical implication of model selection:<\/strong> Test your specific agent workflow with multiple models before committing. Agentic performance does not always correlate with benchmark performance. The model that is best at code generation may not be best at multi-step tool use planning. Empirical testing on your actual task beats relying on leaderboard rankings.<\/p>\n\n\n\nPillar 3: Tools \u2014 Giving the Agent Hands<\/h3>\n\n\n\n A reasoning engine without the ability to act is not an agent. It is an elaborate planning document. Tools are what convert the agent’s plans into effects in the real world.<\/p>\n\n\n\n
In the technical sense, a “tool” is a function that the LLM can decide to call. The function definition\u2014its name, description, and parameter schema\u2014is passed to the model alongside the user’s goal. When the model determines that calling that function is the appropriate next step, it returns a structured tool call specification. Your application executes the function, captures the result, and returns it to the model for the next reasoning step.<\/p>\n\n\n\n
The range of what tools can do:<\/strong><\/p>\n\n\n\nSearch and retrieval tools<\/em> let the agent query a vector store, run a web search, look up a database record, or read a file. These extend the agent’s perception beyond what was loaded into its initial context.<\/p>\n\n\n\nAPI tools<\/em> let the agent interact with external services\u2014calling a payment API to check transaction status, querying a CRM to retrieve customer history, calling a calendar API to check availability, or hitting an internal microservice to fetch real-time data.<\/p>\n\n\n\nBrowser and web tools<\/em> let the agent navigate the web\u2014a capability that is increasingly relevant for research agents, competitive intelligence workflows, and any task that requires interacting with systems that do not have programmatic APIs.<\/p>\n\n\n\nWrite and action tools<\/em> let the agent change state\u2014creating a record, sending an email, updating a database entry, submitting a form, triggering a workflow. These are the highest-stakes tools because their effects are often irreversible. Design write tools with explicit confirmation requirements for any action above a defined impact threshold.<\/p>\n\n\n\nTool design is product design:<\/strong><\/p>\n\n\n\nThe description you write for each tool is not documentation\u2014it is the signal the model uses to decide whether and when to invoke that tool. A poorly described tool will be invoked at wrong moments or missed at right moments. Write tool descriptions from the perspective of the model making a routing decision: what is the precise situation in which this tool is the right next action? What would be the wrong situations to use it?<\/p>\n\n\n
\n
Pillar 4: Memory \u2014 Short-Term Context and Long-Term Recall<\/h3>\n\n\n\n Memory is what separates a stateless AI call from an agent that can operate over extended time horizons and accumulate knowledge across interactions.<\/p>\n\n\n\n
Short-term memory: the context window<\/strong><\/p>\n\n\n\nWithin a single agent execution, short-term memory is the model’s context window\u2014the accumulated record of the agent’s goal, its reasoning steps, the tools it has called, and the results it has received. Everything the agent has done and seen in the current session lives here.<\/p>\n\n\n\n
The critical engineering constraint is that context windows are finite. A GPT-4o context window of 128,000 tokens sounds large until you consider that a multi-step agent executing 10 tool calls, each returning a 1,000-token result, plus its system prompt, plus the conversation history, can consume that budget faster than intuition suggests. Context management\u2014deciding what to keep, what to summarise, and what to drop from the active context\u2014is a non-trivial engineering problem for long-running agents.<\/p>\n\n\n\n
Long-term memory: vector databases and persistent stores<\/strong><\/p>\n\n\n\nBetween sessions and across users, agents need access to information that persists beyond any individual context window. This is where vector databases (Pinecone, Weaviate, pgvector) serve a memory function distinct from their RAG function.<\/p>\n\n\n\n
When an agent completes a task, relevant facts can be extracted and stored as embeddings in the vector store\u2014the user’s preferences, the outcome of a previous interaction, a learned fact about the business domain. In future sessions, these stored memories can be retrieved and injected into the agent’s context, giving it access to a history that is larger than any single context window could hold.<\/p>\n\n\n\n
Structured databases serve a complementary role for factual, relational memory\u2014user profiles, task histories, approval records, and audit logs. An agent that needs to recall “what actions did I take for this user last week” is better served by a structured database query than a vector similarity search.<\/p>\n\n\n\n
Episodic memory and reflection:<\/strong><\/p>\n\n\n\nSome production agents implement an episodic memory system where, at the end of each session, the agent generates a structured summary of what happened\u2014what it was asked to do, what it did, what succeeded, and what failed. This summary is stored and made available in future sessions, allowing the agent to reason about its own history and adjust its approach accordingly. This pattern is particularly valuable for long-running business agents that operate repeatedly over the same domain.<\/p>\n\n\n\n
Framework Comparison: The 2026 Standards for Multi-Agent Orchestration<\/h2>\n\n\n\n Building agentic systems without a framework is possible the same way building a web application without a framework is possible\u2014but the frameworks exist because they solve real, recurring problems, and using them accelerates development significantly. These are the three frameworks that have achieved genuine production adoption for autonomous AI workflows.<\/p>\n\n\n\n
CrewAI: Role-Based Multi-Agent Teams<\/h3>\n\n\n\n CrewAI is built around the metaphor of a professional team. You define agents as roles\u2014a Researcher agent, a Writer agent, an Editor agent, a Data Analyst agent\u2014each with its own system prompt, its own set of tools, and its own goal. You then define tasks and assign them to agents. CrewAI orchestrates the sequential or parallel execution of those tasks, passing outputs between agents as inputs to the next step.<\/p>\n\n\n\n
When CrewAI is the right choice:<\/strong><\/p>\n\n\n\nCrewAI shines when your workflow maps naturally onto a division of labour. Content generation pipelines (research \u2192 draft \u2192 edit \u2192 publish), analysis workflows (collect \u2192 clean \u2192 analyse \u2192 summarise), or software development simulations (plan \u2192 implement \u2192 test \u2192 review) all have a team structure that CrewAI’s mental model represents cleanly.<\/p>\n\n\n\n
The role-based abstraction also makes CrewAI workflows easier to reason about, debug, and explain to non-technical stakeholders. “The Researcher finds the data, the Analyst interprets it, the Writer produces the report” is a workflow that a product manager can understand and contribute requirements to.<\/p>\n\n\n\n
Limitations to understand:<\/strong> CrewAI’s sequential and hierarchical orchestration works well for workflows with predictable structure. When workflows require dynamic, conditional branching based on intermediate results\u2014where the next step genuinely cannot be determined until the previous step completes and its output is evaluated\u2014CrewAI’s structure becomes constraining.<\/p>\n\n\n\nLangGraph: Complex Cyclic Workflows with Human-in-the-Loop<\/h3>\n\n\n\n LangGraph models your agent workflow as a directed graph. Nodes are processing steps\u2014an LLM call, a tool execution, a conditional check, a human approval gate. Edges define how control flows between nodes, including conditional edges that route to different nodes based on the output of a previous node.<\/p>\n\n\n\n
When LangGraph is the right choice:<\/strong><\/p>\n\n\n\nLangGraph is the right framework when your workflow is not a straight line. Agentic loops\u2014where the agent reasons, acts, observes the result, and decides whether to act again or terminate\u2014are modelled naturally as cyclic graphs. Conditional routing\u2014where a low-confidence result triggers a different path than a high-confidence result\u2014is implemented as a conditional edge.<\/p>\n\n\n\n
Most importantly, LangGraph has first-class support for human-in-the-loop checkpoints. You can define nodes in the graph where execution pauses and waits for human input before continuing. This is not an afterthought\u2014it is a core design feature intended for production agents where certain actions require human approval before being executed. For agents that handle financial transactions, legal documents, or any irreversible action, this capability is not optional. It is what makes the agent safe to deploy.<\/p>\n\n\n\n
LangGraph’s state management is also robust\u2014workflow state is explicitly typed and checkpointed, enabling pause and resume across sessions, retry of failed nodes without restarting the entire workflow, and full observability of what the agent did and decided at every step.<\/p>\n\n\n\n
Limitations to understand:<\/strong> LangGraph’s graph abstraction is more verbose than CrewAI’s role abstraction. Defining nodes, edges, and state schemas requires more upfront code. For simple workflows, this overhead is not justified. LangGraph’s value emerges with complexity\u2014the more conditional, cyclic, and long-running your workflow, the more value the explicit graph structure provides.<\/p>\n\n\n\nMicrosoft AutoGen: Conversational Multi-Agent Collaboration<\/h3>\n\n\n\n AutoGen takes a different approach. Agents in AutoGen are conversational participants. They communicate with each other through a structured conversation\u2014one agent proposes an action, another critiques it, a third refines it\u2014with an orchestrator agent managing the conversation flow and determining when consensus has been reached.<\/p>\n\n\n\n
When AutoGen is the right choice:<\/strong><\/p>\n\n\n\nAutoGen is particularly effective for tasks that benefit from multiple perspectives on the same problem\u2014code review workflows where a generator and a critic iterate toward correct code, research synthesis where multiple agents each explore a different angle before a synthesiser combines their outputs, or collaborative decision-making where different agents represent different constraints or stakeholders.<\/p>\n\n\n\n
AutoGen’s conversational model also makes it natural for workflows where the agents need to negotiate or debate. If you want a workflow where a “conservative” agent and an “aggressive” agent argue about a business recommendation and a “judge” agent weighs the arguments, AutoGen’s conversational structure represents this pattern more cleanly than graph-based or role-based frameworks.<\/p>\n\n\n\n
Limitations to understand:<\/strong> AutoGen’s conversational model can be verbose and expensive\u2014agents that debate at length consume tokens proportional to the conversation length. For straightforward task execution where debate is not needed, the overhead is wasteful. AutoGen also has a higher learning curve than CrewAI for simple workflows, as its conversational abstractions require more careful design.<\/p>\n\n\n\nfrom openai import OpenAI\n\nclient = OpenAI(api_key=\"YOUR_API_KEY\")\n\n--- Agent Definitions ---\n\ndef planner_agent(task):\nprompt = f\"Break this task into clear steps:\\n{task}\"\nresponse = client.chat.completions.create(\nmodel=\"gpt-4o-mini\",\nmessages=[{\"role\": \"user\", \"content\": prompt}]\n)\nreturn response.choices[0].message.content\n\ndef researcher_agent(plan):\nprompt = f\"Research and expand on this plan:\\n{plan}\"\nresponse = client.chat.completions.create(\nmodel=\"gpt-4o-mini\",\nmessages=[{\"role\": \"user\", \"content\": prompt}]\n)\nreturn response.choices[0].message.content\n\ndef writer_agent(research):\nprompt = f\"Write a polished final answer based on:\\n{research}\"\nresponse = client.chat.completions.create(\nmodel=\"gpt-4o-mini\",\nmessages=[{\"role\": \"user\", \"content\": prompt}]\n)\nreturn response.choices[0].message.content\n\n--- Crew Orchestration ---\n\ndef run_crew(user_task):\nprint(\"\ud83e\udde0 Planner Agent working\u2026\")\nplan = planner_agent(user_task)\n\nprint(\"\ud83d\udd0d Researcher Agent working...\")\nresearch = researcher_agent(plan)\n\nprint(\"\u270d\ufe0f Writer Agent working...\")\nfinal_output = writer_agent(research)\n\nreturn final_output\n\n# --- Run Example ---\nif __name__ == \"__main__\":\n task = \"Explain how to start a tech career in Mumbai\"\n result = run_crew(task)\n print(\"\\n\u2705 Final Output:\\n\")\n print(result)<\/code><\/pre>\n\n\n\nHow to Build Your First Agent: A 3-Step Roadmap<\/h2>\n\n\n\n Understanding the pillars and frameworks is necessary but not sufficient. Here is the concrete starting point for developers building their first agent.<\/p>\n\n\n\n
Step 1: Define the Persona \u2014 Role, Goal, and Constraints<\/h3>\n\n\n\n The first decision in building an agent is the one most developers undervalue. Before writing any code, define in plain language:<\/p>\n\n\n\n
What role does this agent play?<\/strong> Not “an AI assistant” but a specific role with a specific domain: “a customer support agent for a SaaS billing product” or “a research agent that finds and summarises competitor pricing information” or “a code review agent that evaluates Python pull requests against a defined style guide.”<\/p>\n\n\n\nWhat is the agent’s goal for a given task?<\/strong> This is distinct from the role. The role is persistent; the goal is per-task. “Given a customer support ticket, the agent’s goal is to resolve the customer’s issue using available documentation\u2014and, if it cannot, to draft a response that acknowledges the issue and escalates with a clear summary of what was tried.”<\/p>\n\n\n\nWhat are the agent’s constraints?<\/strong> This is the most overlooked part of persona definition and the source of most production agent failures. What is the agent explicitly not allowed to do? What actions require confirmation before execution? What topics or domains are out of scope? Constraints belong in the system prompt, stated clearly and specifically. Vague constraints (“be careful with sensitive data”) produce vague agent behaviour. Specific constraints (“never include the customer’s full credit card number in any response or tool call argument”) produce specific, enforceable agent behaviour.<\/p>\n\n\n\nThe system prompt is the agent’s operating manual. Write it with the same care you would give to a document that will govern consequential behaviour\u2014because it will.<\/p>\n\n\n\n
Step 2: Equip with Tools \u2014 Start Minimal, Expand Deliberately<\/h3>\n\n\n\n The instinct when equipping an agent with tools is to give it everything it might conceivably need. This instinct produces agents that are expensive (more tools means longer context for the tool definitions), slower (the model takes longer to select from a large tool set), and less reliable (more tools means more opportunities for the wrong tool to be selected).<\/p>\n\n\n\n
Start with the minimum tool set required for the core use case. For a research agent: a web search tool and a document summarisation tool. For a customer support agent: a knowledge base retrieval tool and a ticket creation tool. For a data analysis agent: a database query tool and a code execution tool.<\/p>\n\n\n\n
Each tool requires:<\/p>\n\n\n\n
A name that is unambiguous.<\/strong> search_knowledge_base<\/code> is better than search<\/code>. create_support_ticket<\/code> is better than create<\/code>. When the model has multiple tools, name collisions and near-collisions cause selection errors.<\/p>\n\n\n\nA description that specifies when to use it and when not to.<\/strong> Include the positive case (“use this when the user is asking about their account balance”) and the negative case (“do not use this for questions about billing disputes\u2014use the billing_query tool instead”).<\/p>\n\n\n\nA parameter schema that validates inputs.<\/strong> Every parameter should have a type, a description, and\u2014where relevant\u2014an enum of valid values. This catches malformed tool calls before they reach your backend and makes the model’s tool use more reliable by constraining the space of possible inputs.<\/p>\n\n\n\nTest each tool independently before testing the agent. A tool that fails when called in isolation will fail when the agent calls it, and diagnosing the failure is significantly harder when it is embedded in an agent execution.<\/p>\n\n\n\n
Step 3: The Execution Loop \u2014 Think, Act, Observe<\/h3>\n\n\n\n The agentic execution loop is the mechanism by which an agent pursues a goal over multiple steps. Understanding it clearly is the foundation for debugging agents when they misbehave\u2014which they will.<\/p>\n\n\n\n
Think:<\/strong> The model receives the current state (goal + context + memory + available tools + history of previous steps) and produces a reasoning output. In most frameworks, this reasoning is explicit\u2014the model produces a “thought” before deciding on an action. This thought is the agent’s current understanding of where it is in the task and what it should do next. Making thoughts explicit and logging them is essential for debugging.<\/p>\n\n\n\nAct:<\/strong> Based on its reasoning, the model produces a tool call\u2014a specific function to invoke with specific arguments. The application layer executes the tool call and captures the result. If the tool call fails, the error is returned to the model as the observation.<\/p>\n\n\n\nObserve:<\/strong> The result of the tool call (or the error) is appended to the agent’s context as an observation. The model now has new information. It reasons again: is the task complete? If yes, produce the final response. If no, what should the next action be?<\/p>\n\n\n\nThis loop continues until one of three conditions is met: the model determines the task is complete, the model determines the task cannot be completed (and explains why), or the maximum iteration limit is reached (a safety constraint you define to prevent runaway loops).<\/p>\n\n\n\n
The maximum iteration limit is not optional.<\/strong> Every production agent needs a defined ceiling on the number of reasoning steps. Without it, a confused agent\u2014one that is not making progress but also not recognising that it is stuck\u2014will continue consuming compute and API credits indefinitely. Set the limit conservatively for your initial deployment and adjust based on observed behaviour.<\/p>\n\n\n\nThe Reliability Gap: What Separates Demos from Production<\/h2>\n\n\n\n A point worth stating directly: agentic AI systems are significantly harder to make reliable than generative AI features, and the gap between a demo that works and an agent that works reliably at production scale is larger than most developers expect.<\/p>\n\n\n\n
Agents fail in ways that are qualitatively different from traditional software failures. A poorly written function either crashes or produces wrong output\u2014both are detectable. An agent that reasons incorrectly may produce a confident, well-structured, plausible result that is wrong in a way that is subtle and hard to detect without domain expertise.<\/p>\n\n\n\n
Sources of reliability failure in production agents:<\/strong><\/p>\n\n\n\nCompounding errors:<\/em> An incorrect tool call in Step 2 produces incorrect output. That output becomes the input to Step 3, which compounds the error. By Step 6, the agent is operating on a completely incorrect basis. Each individual step looked reasonable; the composition was catastrophic. Mitigation: validate tool outputs before feeding them back to the model, and build observation steps where the model explicitly checks whether the retrieved information is relevant before proceeding.<\/p>\n\n\n\nGoal drift:<\/em> In long-running agents, the model can gradually drift from the original goal as the context fills with intermediate results. The latest observations crowd out the original goal statement. Mitigation: periodically reinject the original goal into the context, and build explicit goal-checking steps into long workflows.<\/p>\n\n\n\nPremature termination:<\/em> Some models will produce a final answer when they should continue\u2014deciding that the task is “close enough” rather than fully complete. This is particularly common when the remaining steps are ambiguous. Mitigation: write task completion criteria explicitly in the system prompt, and include an explicit self-check step (“Have I fully completed the goal as defined? If not, what is the next required action?”).<\/p>\n\n\n\nTool misuse:<\/em> The model calls the right tool but with subtly wrong arguments\u2014a date formatted incorrectly, a filter applied too broadly, a field referenced by the wrong name. Mitigation: strong parameter validation in tool schemas, and clear error messages that tell the model what was wrong and how to correct it.<\/p>\n\n\n\nThese failure modes are not reasons to avoid building agents. They are reasons to build agents with explicit reliability engineering from the start\u2014not as an afterthought.<\/p>\n\n\n\n
Autonomous AI Workflows: Where This Is Going<\/h2>\n\n\n\n Multi-agent orchestration and autonomous AI workflows are not a speculative future technology. They are in production at companies building competitive advantages right now. Customer support systems that resolve 60% of tickets without human intervention. Research pipelines that synthesise competitor intelligence across hundreds of sources overnight. Code review agents that catch security vulnerabilities before human reviewers see the PR. Data analysis workflows that run on a schedule, detect anomalies, and generate natural language reports for business stakeholders.<\/p>\n\n\n\n
In 2026, the question is not whether agentic AI will be used in your industry. It is whether you will be the engineer who builds it, or the one who is handed it to maintain without understanding how it works.<\/p>\n\n\n\n
The architecture is learnable. The frameworks are production-ready. The failure modes are understood. What is missing, for most development teams, is a structured program that takes the theory covered in a guide like this and turns it into the hands-on experience of building, deploying, and debugging agentic systems against real-world problem complexity.<\/p>\n\n\n\n
The Future Is Agentic. Are You Ready?<\/h2>\n\n\n\n Join TechPaathshala’s Agentic AI Mastery Program<\/strong> and learn to build, deploy, and scale autonomous agents for real-world business.<\/p>\n\n\n\nThe program is designed for software engineers and full stack developers who are ready to move beyond LLM prompting into production agentic systems. Curriculum covers the four-pillar architecture, hands-on implementation in CrewAI and LangGraph, tool design and function calling patterns, memory architecture, multi-agent orchestration, reliability engineering, and deployment on cloud infrastructure.<\/p>\n\n\n\n
You will leave with deployed, multi-agent systems in your portfolio\u2014built to production standards, not tutorial scaffolding. The kind of work that positions you at the frontier of what AI engineering means in 2026.<\/p>\n\n\n\n
Apply for the Agentic AI Mastery Program \u2192<\/a><\/strong><\/p>\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
Something changed in how developers talk about AI somewhere around late 2024. The conversation shifted from “what can I generate?” to “what can I automate?” The products that started getting attention were not better chatbots. They were systems that could be given a goal and left to pursue it\u2014researching, deciding, executing, and reporting back without […]<\/p>\n","protected":false},"author":1,"featured_media":840,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"","ocean_second_sidebar":"","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"","ocean_custom_header_template":"","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"","ocean_menu_typo_font_family":"","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"","ocean_post_title_background_color":"","ocean_post_title_background":0,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"","ocean_post_oembed":"","ocean_post_self_hosted_media":"","ocean_post_video_embed":"","ocean_link_format":"","ocean_link_format_target":"self","ocean_quote_format":"","ocean_quote_format_link":"post","ocean_gallery_link_images":"on","ocean_gallery_id":[],"footnotes":""},"categories":[82],"tags":[],"class_list":["post-761","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gen-ai","entry","has-media"],"acf":[],"_links":{"self":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts\/761","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/comments?post=761"}],"version-history":[{"count":2,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts\/761\/revisions"}],"predecessor-version":[{"id":963,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/posts\/761\/revisions\/963"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/media\/840"}],"wp:attachment":[{"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/media?parent=761"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/categories?post=761"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techpaathshala.com\/blog\/wp-json\/wp\/v2\/tags?post=761"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Advertisement\"](\"https:\/\/techpaathshala.com\/blog\/wp-content\/uploads\/2026\/04\/WhatsApp-Image-2026-04-20-at-11.47.34-AM-2.jpeg\")
<\/a><\/div>\n\n\n\n![\"\"](\"https:\/\/techpaathshala.com\/blog\/wp-content\/uploads\/2026\/04\/images-3.png\")
<\/figure>\n<\/div>\n\n\n